moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

Merge branches 'feature/xep-0412', 'feature/xep-0050', 'feature/xep-0277', 'feature/xep-0199', 'feature/xep-0405', 'feature/xep-0369', 'feature/eax-references' and 'feature/protoxep-automatic-trust-transfer'

Browse Source
This commit is contained in:
Jonas Schäfer 2019-03-26 16:45:08 +01:00
commit 51822e2d1d
9 changed files with 554 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

431
inbox/automatic-trust-transfer.xml Normal file
View File

@ -0,0 +1,431 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY omemo-glossary "<span class='ref'><link url='https://xmpp.org/extensions/xep-0384.html#glossary-general'>OMEMO glossary</link></span> <note>OMEMO glossary &lt;<link url='https://xmpp.org/extensions/xep-0384.html#glossary-general'>https://xmpp.org/extensions/xep-0384.html#glossary-general</link>&gt;.</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Automatic Trust Transfer (ATT)</title>
<abstract>
ATT specifies an automatic transfer of trust in public identity keys used by the end-to-end encryption protocol OMEMO.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0147</spec>
<spec>XEP-0384</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Melvin</firstname>
<surname>Keskin</surname>
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2019-03-22</date>
<initials>mk</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
ATT is used in conjunction with &xep0384; for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones.
It preserves the security level as if all devices had authenticated their keys manually.
A trusted third party is not required since an ordinary OMEMO message is used for transferring the information needed to authenticate a public identity key or revoke the trust in that key.
Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated public identity keys.
That means an attacker cannot detect whether an authentication or revocation took place.
</p>
<p>
End-to-end encryption without verifying the authenticity of the exchanged public identity keys only enables users to protect their communication against passive attacks.
This means an attacker cannot read encrypted messages in transit without actively intervening in the key exchange.
However, without any other precautions active attacks are still possible.
If an attacker replaces the exchanged keys with malicious ones, the end-to-end encrypted messages can be read and manipulated by the attacker.
</p>
<p>
When using OMEMO, a public identity key is transmitted over a channel which is not protected against active attacks.
That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages.
</p>
<p>
When using OMEMO, each device has a unique identity key.
For that reason it is not necessary to copy an existing private identity key to a new device enabling it to use end-to-end encryption.
Additionally, it can be used to stop encrypting for a specific device.
For example, that could be done automatically after a given number of sent messages without any reaction from the receiving device that would forward the double ratchet to ensure forward and backward secrecy.
</p>
<p>
However, the downside of that approach is that it increases the number of key authentications users need to do for each new device to be protected against active attacks.
Without ATT all n-1 mutual authentications per new key have to be done manually.
With ATT though, only one mutual manual authentication per new key is required.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>OMEMO message</dt>
<dd>Message encrypted using OMEMO</dd>
</di>
<di>
<dt>Device</dt>
<dd>See <cite>Device</cite> in &omemo-glossary;</dd>
</di>
<di>
<dt>Key</dt>
<dd>Public part of <cite>IdentityKey</cite> in &omemo-glossary;</dd>
</di>
<di>
<dt>Key identifier</dt>
<dd>Identifier for a key (e.g., a fingerprint or the key itself)</dd>
</di>
<di>
<dt>Key authentication</dt>
<dd>Verification that a key received over an insecure channel is actually the one of the assumed device</dd>
</di>
<di>
<dt>Manual key authentication</dt>
<dd>Key authentication with user interaction (e.g., QR code scanning, fingerprint verification)</dd>
</di>
<di>
<dt>Automatic key authentication</dt>
<dd>Key authentication without user interaction (e.g., via ATT)</dd>
</di>
<di>
<dt>Mutual key authentication</dt>
<dd>Key authentication in which two devices authenticate each other's key</dd>
</di>
<di>
<dt>Key revocation</dt>
<dd>Revoking the trust in a key</dd>
</di>
<di>
<dt>Manual key revocation</dt>
<dd>Key revocation with user interaction (e.g., clicking a "Revoke" button)</dd>
</di>
<di>
<dt>Automatic key revocation</dt>
<dd>Key revocation without user interaction (e.g., via ATT)</dd>
</di>
<di>
<dt>Trust message</dt>
<dd>
OMEMO message which indicates that specific keys can be trusted (authentication) or no longer trusted (revocation).
A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation.
</dd>
</di>
<di>
<dt>Authentication message</dt>
<dd>
Trust message which only contains key identifiers for authentication.
If a trust message contains authentication and revocation parts, the term authentication message is used for referring to the trust message without revocation parts.
</dd>
</di>
<di>
<dt>Revocation message</dt>
<dd>
Trust message which only contains key identifiers for revocation.
If a trust message contains authentication and revocation parts, the term revocation message is used for referring to the trust message without authentication parts.
</dd>
</di>
</dl>
</section1>
<section1 topic='Advantages' anchor='advantages'>
<p>
The goal of key authentication is to create an end-to-end encrypted communication network exclusively of devices with authenticated keys.
As a result every communication channel between those devices is resistant against active attacks.
</p>
<p>
The network of devices which authenticated each other's keys can be seen as a complete graph where each device is a node and each mutual authentication is an edge.
The number of edges grows for each new device by the number of existing nodes.
This is due to the fact that in order to sustain secure channels between all devices, a new key has to be authenticated by all n existing devices and vice versa.
</p>
<p>
One of those n mutual authentications requires user interaction like scanning each other's QR code or comparing each other's key identifier by hand.
That is the initial mutual manual authentication.
The remaining authentications can be automated relying on the secure channel established by the inital mutual manual authentication and the secure channels already created by the same procedure between the rest of the devices.
</p>
<p>
For creating the described complete graph with n nodes, a total of T(n) = (n*(n-1))/2 ∊ O(n²) mutual authentications are needed.
When using ATT, only T(n) = n-1 ∊ O(n) of them have to be made manually.
All remaining authentications can be performed automatically.
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level.
</p>
</section1>
<section1 topic='General Procedure' anchor='general-procedure'>
<p>
This section explains the basic procedure of autmomatically authenticating or revoking a key by a trust message.
It does not specify the detailed behaviour which can be found in section <link url='#usecases'>Use Cases</link>.
Instead, this section should rather show the fundamental idea behind ATT.
</p>
<section2 topic='Authentication' anchor='general-procedure-authentication'>
<ol>
<li>
<p>
Device 1 manually authenticates the key of device 2.
Device 1 automatically sends an authentication message for device 2's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 2.
</p>
</li>
<li>
<p>
Device 2 manually authenticates the key of device 1.
Device 2 automatically sends an authentication message for device 1's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 1.
</p>
</li>
<li>
<p>
Device 1 automatically authenticates the keys of the authentication message from device 2.
Each device receiving an authentication message from device 1 automatically authenticates device 2's key, if device 1's key has already been authenticated by it.
Each device receiving an authentication message from device 2 automatically authenticates the corresponding keys, if device 2's key has been authenticated by it.
</p>
</li>
<li>
<p>
Device 2 automatically authenticates the keys of the authentication message from device 1.
Each device receiving an authentication message from device 2 automatically authenticates device 1's key, if device 2's key has already been authenticated by it.
Each device receiving an authentication message from device 1 automatically authenticates the corresponding keys, if device 1's key has been authenticated by it.
</p>
</li>
</ol>
</section2>
<section2 topic='Revocation' anchor='general-procedure-revocation'>
<p>
Device 1 manually revokes the trust in the key of device 2.
Device 1 automatically sends a revocation message for device 2's key to devices whose keys it has already authenticated.
Each device receiving a revocation message from device 1 automatically revokes the trust in device 2's key, if device 1's key has already been authenticated by it.
</p>
</section2>
</section1>
<section1 topic='Trust Message URI' anchor='trust-message-uri'>
<p>
A trust message contains an <cite>XMPP URI</cite> (see &xep0147;) defined by the following scheme:
</p>
<example caption='Scheme of a Trust Message URI'><![CDATA[xmpp:<bare-jid>?omemo-trust;<auth|revoke>=<key-identifier-1>;<auth|revoke>=<key-identifier-2>;<...>;<auth|revoke>=<key-identifier-n>]]></example>
<example caption='Example of a Trust Message URI'><![CDATA[xmpp:user@example.org?omemo-trust;auth=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;auth=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e;revoke=b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413]]></example>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>
Alice would like to use OMEMO when communicating with Bob.
Alice has the devices A1, A2 and A3.
Bob has the device B1.
A1 has already authenticated A2's key.
The other devices have not authenticated each other's key.
</p>
<p>
Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them.
</p>
<section2 topic='Authenticating the Key of a Contact&apos;s Device' anchor='usecases-authentication-contact-device'>
<section3 topic='Sending' anchor='usecases-authentication-contact-device-sending'>
<p>
Example:
A1 authenticates B1's key.
</p>
<p>
A device that manually authenticates the key of a contact's device MUST send an authentication message for
</p>
<ol>
<li>
<p>
the key that has been authenticated, to each own device with an already authenticated key.
</p>
<p>
Example:
A1 sends an authentication message for B1's key to A2.
</p>
</li>
<li>
<p>
each already authenticated key of all own devices, to the device whose key has been authenticated.
</p>
<p>
Example:
A1 sends an authentication message for A2's key to B1.
</p>
</li>
</ol>
</section3>
<section3 topic='Receiving' anchor='usecases-authentication-contact-device-receiving'>
<p>
A device that receives an authentication message for a key of a contact's device from
</p>
<ol>
<li>
<p>
an own device
</p>
<p>
Example:
A2 authenticates B1's key by the authentication message from A1 as soon as A2 authenticated A1's key.
</p>
</li>
<li>
<p>
or another device of that contact
</p>
<p>
Example:
B1 authenticates A2's key by the authentication message from A1 as soon as B1 authenticated A1's key.
</p>
</li>
</ol>
<p>
MUST authenticate the key as soon as the receiving device authenticated the key of the device which sent the authentication message.
</p>
</section3>
</section2>
<section2 topic='Authenticating the Key of an Own Device' anchor='usecases-authentication-own-device'>
<section3 topic='Sending' anchor='usecases-authentication-own-device-sending'>
<p>
Example:
A2 has already authenticated A1's and B1's key.
A2 authenticates A3's key.
</p>
<p>
A device that manually authenticates the key of an own device MUST send an authentication message for
</p>
<ol>
<li>
<p>
the key that has been authenticated to each other device with an already authenticated key.
</p>
<p>
Example:
A2 sends an authentication message for A3's key to A1 and B1.
</p>
</li>
<li>
<p>
each already authenticated key of all devices to the device whose key has been authenticated.
</p>
<p>
Example:
A2 sends an authentication message for A1's and B1's key to A3.
</p>
</li>
</ol>
</section3>
<section3 topic='Receiving' anchor='usecases-authentication-own-device-receiving'>
<p>
A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the receiving device authenticated the key of the device which sent the authentication message.
</p>
<p>
Example:
A1 authenticates A3's key by the authentication message from A2 as soon as A1 authenticated A2's key.
</p>
</section3>
</section2>
<section2 topic='Revoking the Trust in a Key' anchor='usecases-revocation'>
<p>
A client MAY send a revocation message for a key that is not trusted anymore by the sending client so that key will no longer be trusted by the receiving client.
A client receiving a revocation message SHOULD revoke the trust in the corresponding key.
</p>
<p>
// TODO Further discussion has to take place before finalizing this section.
</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Storing Trust Message Information from Devices with Unauthenticated Keys' anchor='impl-storing-trust-message-information-unauthenticated-keys'>
<p>
A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked.
Afterwards the information of the trust message MAY be deleted.
</p>
<p>
Example:
When Alice's device A1 authenticates the key of Bob's device B1, A1 sends a trust message containing the keys of Alice's other device A2 to B1.
If B1 has not already authenticated A1's key, B1 stores the information provided by the trust message.
B1 authenticates A1's key and is then able to automatically authenticate A2's key.
</p>
</section2>
<section2 topic='Storing Trust Message Information for Unknown Keys' anchor='impl-storing-trust-message-information-unknown-keys'>
<p>
A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
Example:
Alice's device A1 receives an authentication message from Bob's device B1.
That authentication message contains the key for Bob's other device B2.
If A1 has not already fetched B2's key, A1 stores the information provided by the trust message.
A1 fetches B2's key and is then able to automatically authenticate A2's key.
</p>
</section2>
<section2 topic='Reducing The Number of Trust Messages' anchor='impl-reducing-number-of-trust-messages'>
<section3 topic='Using URIs Containing Multiple Keys' anchor='impl-reducing-number-of-trust-messages-uris-multiple-keys'>
<p>
For reducing the number of trust messages sent to a device, a client MAY use a URI containing multiple keys that have been authenticated shortly after another.
</p>
<p>
Example:
Alice's device A1 authenticates the keys of Bob's devices B1 and B2 after scanning Bob's QR code containing their key identifiers.
A1 sends one authentication message for all of the authenticated keys.
</p>
</section3>
<section3 topic='Using Message Carbons' anchor='impl-reducing-number-of-trust-messages-message-carbons'>
<p>
Furthermore, a client MAY use &xep0280; for sending a trust message to all devices of a contact or to all own devices at once.
Then, by sending a trust message to the contact, each device of the contact and each own device gets the same trust message by the server.
Thus, a client needs to send the same trust message only once.
If not all devices of the contact should receive the trust message, the trust message MAY be sent to specific devices of the contact but for all own devices Message Carbons MAY be used and vice versa.
Even when a client does not already have a contact, the client MAY use Message Carbons for delivering a trust message to all own devices.
</p>
<p>
Example:
Alice's device A1 authenticates the key of her device A2.
A1 sends the trust message for A2's key only once to all of Alice's and Bob's devices by using Message Carbons.
</p>
<p>
Attention:
In that context, sending a trust message to all devices of a contact or to all own devices does not mean to encrypt it with the keys of all those devices.
Instead, it only means that all of those devices should receive the trust message even if it is not encrypted for some of them and thereby not decryptable by those devices.
Keep in mind that a trust message MUST only be encrypted for devices with authenticated keys.
</p>
<p>
The drawback of using Message Carbons is that clients may show a message to the user that an OMEMO message received which has not been encrypted for the corresponding device.
</p>
</section3>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Notification' anchor='security-notification'>
<p>
A client that receives a trust message SHOULD NOT display its bare content to the user.
Instead, the message SHOULD be hidden and the automatic authentication or revocation SHOULD take place in the background.
After a successful authentication or revocation, the user MAY be informed of that event.
The client MAY offer an option for requesting the user's confirmation before any automatic authentication or automatic revocation is performed.
</p>
</section2>
<section2 topic='Recommended Security Policy' anchor='security-policy'>
<p>
It is more secure to be protected against passive attacks instead of not using any encryption.
If it is not possible to authenticate a key before encrypting with it but it is desired to communicate with the key's device, it is RECOMMENDED to blindly trust new keys until the first authentication has been made.
</p>
<p>
Even ATT cannot protect the user against an attacker with a blindly trusted and undetected malicious key.
For this reason it is important to take special care of the following security aspects.
</p>
<p>
If keys are blindly trusted until the first authentication, keys which are not authenticated by then MUST NOT be used any longer for encryption until they have been authenticated too.
New keys MUST also only be used for encryption after they have been authenticated.
Without these two additional precautions it is not possible to protect the user against attackers who introduced malicious keys before or after the first authentication.
</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>REQUIRED.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>REQUIRED.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>REQUIRED for protocol specifications.</p>
</section1>
</xep>

8
xep-0050.xml
View File

@ -25,6 +25,12 @@
<url>http://www.xmpp.org/schemas/commands.xsd</url>
</schemaloc>
&linuxwolf;
<revision>
<version>1.2.3</version>
<date>2019-03-26</date>
<initials>XEP Editor (jsc)</initials>
<remark>Fix typo in example (mode =&gt; runlevel)</remark>
</revision>
<revision>
<version>1.2.2</version>
<date>2016-12-03</date>
@ -418,7 +424,7 @@
sessionid='config:20020923T213616Z-700'
node='config'>
<x xmlns='jabber:x:data' type='submit'>
<field var='mode'>
<field var='runlevel'>
<value>3</value>
</field>
<field var='state'>

8
xep-0199.xml
View File

@ -25,6 +25,12 @@
<url>http://www.xmpp.org/schemas/ping.xsd</url>
</schemaloc>
&stpeter;
<revision>
<version>2.0.1</version>
<date>2019-03-26</date>
<initials>o01eg</initials>
<remark>Fix incorrect IQ type in example (result =&gt; error)</remark>
</revision>
<revision>
<version>2.0</version>
<date>2009-06-03</date>
@ -180,7 +186,7 @@
<iq from='juliet@capulet.lit/chamber'
to='romeo@montague.lit/home'
id='e2e1'
type='result'>
type='error'>
<ping xmlns='urn:xmpp:ping'/>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

12
xep-0277.xml
View File

@ -34,6 +34,12 @@
<jid>valerian@jappix.com</jid>
<uri>https://valeriansaliou.name/</uri>
</author>
<revision>
<version>0.6.3</version>
<date>2019-03-26</date>
<initials>pep</initials>
<remark>Wording fixes</remark>
</revision>
<revision>
<version>0.6.2</version>
<date>2017-11-28</date>
@ -104,7 +110,7 @@
<section1 topic='Protocol' anchor='proto'>
<section2 topic='Location' anchor='location'>
<p>A person's microblog SHOULD be located at a personal eventing (PEP) node whose name is "urn:xmpp:microblog:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account. For instance, if the Shakespearean character Romeo has a JabberID of &lt;romeo@montague.lit&gt; then his microblog would be located at that JID with a node of "urn:xmpp:microblog:0". Outside of native XMPP systems, this node can be referred to as the following XMPP URI (see <cite>XEP-0060 § 12.21</cite>).</p>
<p>A person's microblog SHOULD be located at a personal eventing (PEP) node named "urn:xmpp:microblog:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account. For instance, if the Shakespearean character Romeo has a JabberID of &lt;romeo@montague.lit&gt; then his microblog would be located at that JID with a node of "urn:xmpp:microblog:0". Outside of native XMPP systems, this node can be referred to as the following XMPP URI (see <cite>XEP-0060 § 12.21</cite>).</p>
<code><![CDATA[
xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0
]]></code>
@ -195,7 +201,7 @@ xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0
</event>
</message>
]]></example>
<p>Note: these alternate links were not posted by client because client can't compute them itself. These things SHOULD be inserted at server side though.</p>
<p>Note: these alternate links were not posted by the original client because clients can't compute them themselves. These things SHOULD be inserted at server side though.</p>
</section2>
<section2 topic='Replying to a Post' anchor='reply'>
<p>Anyone can publish a post in reply to Romeo's post. Here we assume that a reply comes from Benvolio.</p>
@ -369,7 +375,7 @@ xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0
</section1>
<section1 topic='Microblog Metadata' anchor='metadata'>
<p>In order to provide users with some metadata (i.e. blog title or author information) about the microblog, the client MUST to add an item with such information. The client MUST set the ID of the item to "0".</p>
<p>In order to provide users with some metadata (i.e. blog title or author information) about the microblog, the client MUST add an item with such information. The client MUST set the ID of the item to "0".</p>
<example caption="Publishing microblog metadata"><![CDATA[
<iq from='romeo@montague.lit/pc'
id='pub8'

124
xep-0369.xml
View File

@ -35,12 +35,24 @@
<shortname>MIX-CORE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.14.2</version>
<date>2019-03-18</date>
<initials>sek</initials>
<remark><p>
Replace &lt;submission-id/&gt; with XEP-0359;
Make Message Archiving Optional;
Clarify that participant node only contains real JIDs;
Change message retrieval from archive to reflect that MIX-PAM archive is now optional;
Bump namespace to core:1;
</p></remark>
</revision>
<revision>
<version>0.14.1</version>
<date>2019-01-05</date>
<initials>lnj</initials>
<remark><p>
Remove MIX xmlns from pubsub channel info &lt;item/&gt; example
Remove MIX xmlns from pubsub channel info &lt;item/&gt; example;
</p></remark>
</revision>
<revision>
@ -621,7 +633,7 @@
<section3 topic="Participants Node" anchor="participants-node">
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:core:0' namespace.
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:core:1' namespace.
</p>
<p>
A Nick MAY be associated with a participant, which provides a user-oriented description of the participant. The nick associated with the user is stored in a &lt;nick/&gt; child element of the &lt;participant/&gt; element. The nick for each channel participant MUST be different to the nick of other participants (where nicks have been assigned).
@ -633,7 +645,7 @@
Where a nick is provided for a user, it is generally recommended to use this nick to display the user. This enables consistent representation of participants for all participants in the channel.
</p>
<p>
The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed.
The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed. Note that only the real JID may be held in participants node. Any JID derived from the stable ID MUST NOT be held.
The user's JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element.
</p>
<p>
@ -649,7 +661,7 @@
<example caption="Value of Participants Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456'>
<participant xmlns='urn:xmpp:mix:core:0'>
<participant xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</participant>
@ -683,7 +695,7 @@
<item id='2016-05-30T09:00:00'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:core:0</value>
<value>urn:xmpp:mix:core:1</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -752,7 +764,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:core:0' feature, and the identity MUST have a category of 'conference' and a type of 'mix', as shown in the following example: </p>
<p>The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:core:1' feature, and the identity MUST have a category of 'conference' and a type of 'mix', as shown in the following example: </p>
<example caption="Service responds with Disco Info result" ><![CDATA[
<iq from='mix.shakespeare.example'
id='lx09df27'
@ -763,18 +775,18 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='urn:xmpp:mix:core:0#searchable'>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mix:core:1#searchable'>
</query>
</iq>
]]></example>
<p>
A MIX service MUST return the 'urn:xmpp:mix:core:0' feature and MAY return the other features listed here:
A MIX service MUST return the 'urn:xmpp:mix:core:1' feature and MAY return the other features listed here:
</p>
<ul>
<li>'urn:xmpp:mix:core:0': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'urn:xmpp:mix:core:0#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.</li>
<li>'urn:xmpp:mix:core:0#create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.</li>
<li>'urn:xmpp:mix:core:1': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'urn:xmpp:mix:core:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.</li>
<li>'urn:xmpp:mix:core:1#create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.</li>
</ul>
<p>A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.</p>
</section2>
@ -823,7 +835,7 @@
category='conference'
name='A Dark Cave'
type='mix'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mam:2'/>
</query>
</iq>
@ -882,7 +894,7 @@
<item id='2016-05-30T09:00:00'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:core:0</value>
<value>urn:xmpp:mix:core:1</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -923,13 +935,13 @@
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456'>
<participant xmlns='urn:xmpp:mix:core:0'>
<participant xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</participant>
</item>
<item id='87123'>
<participant xmlns='urn:xmpp:mix:core:0'>
<participant xmlns='urn:xmpp:mix:core:1'>
<nick>top witch</nick>
<jid>hecate@shakespeare.example</jid>
</participant>
@ -962,7 +974,7 @@
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='urn:xmpp:mix:core:1'/>
</query>
</iq>
]]></example>
@ -977,7 +989,7 @@
</p>
</section3>
<section3 topic='Joining a Channel' anchor='usecase-user-join'>
<p>A user joins a channel by sending a MIX "join" command from one of the user's clients, which will be relayed to the server as specified in MIX-PAM. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. Note that the presence node is specified in MIX-PRESENCE. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:core:0' namespace. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element. A nick MAY be specified as a &lt;nick/&gt; child elements of the &lt;join/&gt; element. </p>
<p>A user joins a channel by sending a MIX "join" command from one of the user's clients, which will be relayed to the server as specified in MIX-PAM. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. Note that the presence node is specified in MIX-PRESENCE. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element. A nick MAY be specified as a &lt;nick/&gt; child elements of the &lt;join/&gt; element. </p>
<p>The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.</p>
<p>The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription to some nodes. This will be handled by clients directly subscribing to the desired PubSub nodes.</p>
<p>The user's server needs to make roster changes as part of the join functionality, as specified in MIX-PAM. This means that the join request to the MIX service will come from the user's server from the user's bare JID.</p>
@ -986,7 +998,7 @@
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:core:0'>
<join xmlns='urn:xmpp:mix:core:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
@ -1003,7 +1015,7 @@
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:core:0'
<join xmlns='urn:xmpp:mix:core:1'
id='123456'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
@ -1025,7 +1037,7 @@
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:core:0'
<join xmlns='urn:xmpp:mix:core:1'
id='123456'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
@ -1044,7 +1056,7 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456'>
<participant xmlns='urn:xmpp:mix:core:0'>
<participant xmlns='urn:xmpp:mix:core:1'>
<jid>hag66@shakespeare.example</jid>
<nick>third witch</nick>
</participant>
@ -1057,14 +1069,14 @@
</p>
<p>
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a &lt;update-subscription/&gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/&gt; element is qualified by the 'urn:xmpp:mix:core:0' namespace. The requested notes are encoded as &lt;subscribe/&gt; child elements of the &lt;update-subscription/&gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a &lt;update-subscription/&gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested notes are encoded as &lt;subscribe/&gt; child elements of the &lt;update-subscription/&gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
</p>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:core:0'>
<update-subscription xmlns='urn:xmpp:mix:core:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
</update-subscription>
</iq>
@ -1073,7 +1085,7 @@
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:core:0'
<update-subscription xmlns='urn:xmpp:mix:core:1'
jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
</update-subscription>
@ -1084,13 +1096,13 @@
</p>
</section3>
<section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element. The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:core:0' namespace. The following example shows a leave request to a MIX channel. </p>
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element. The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
<example caption="User's Server sends Leave Request to a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:core:0'/>
<leave xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
@ -1102,7 +1114,7 @@
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:core:0'/>
<leave xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
<p>When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE.
@ -1134,14 +1146,14 @@
<li>The MIX service generates the nick. </li>
</ol>
<p>
A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a &lt;setnick/&gt; child element of &lt;iq/&gt; element. The &lt;setnick/&gt; element is qualified by the 'urn:xmpp:mix:core:0' namespace. The nick is encoded as a &lt;nick/&gt; child element of the &lt;setnick/&gt; element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a &lt;setnick/&gt; child element of &lt;iq/&gt; element. The &lt;setnick/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The nick is encoded as a &lt;nick/&gt; child element of the &lt;setnick/&gt; element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
</p>
<example caption="User sets Nick on Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='7nve413p'>
<setnick xmlns='urn:xmpp:mix:core:0'>
<setnick xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
</setnick>
</iq>
@ -1155,7 +1167,7 @@
from='coven@mix.shakespeare.example'
to'hag66@shakespeare.example/UUID-a1j/7533'
id='7nve413p'>
<setnick xmlns='urn:xmpp:mix:core:0'>
<setnick xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
</setnick>
</iq>
@ -1186,7 +1198,7 @@
</message>
]]></example>
<p>
The MIX channel then adds information to the message using a &lt;mix&gt; element qualified by the 'urn:xmpp:mix:core:0' namespace. This enables are receiver of the MIX message to determine the message sender. This element contains two child elements:
The MIX channel then adds information to the message using a &lt;mix&gt; element qualified by the 'urn:xmpp:mix:core:1' namespace. This enables are receiver of the MIX message to determine the message sender. This element contains two child elements:
</p>
<ol>
<li>A &lt;nick&gt; element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user.</li>
@ -1204,7 +1216,7 @@
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:0'>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</mix>
@ -1217,7 +1229,7 @@
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:0'>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</mix>
@ -1226,26 +1238,15 @@
<p>
The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional &lt;submission-id&gt; element in the &lt;mix&gt; element of the message copy going back to the originator's bare JID. The &lt;submission-id&gt; element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.
The message originator may wish to correlate the reflected message with the submitted message. To do this, the originator should include an &lt;origin-id&gt; element in the message as specified in &xep0359;.
</p>
<example caption="Channel Reflects Message back to Originator"><![CDATA[
<message from='coven@mix.shakespeare.example/123456'
to='hag66@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:0'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
<submission-id>92vax143g</submission-id>
</mix>
</message>
]]></example>
</section3>
</section2>
<section2 topic="Use of MAM" anchor="use-mam">
<p>
All messages sent to a MIX channel MUST be archived using MAM in association with the MIX channel. All messages MUST also be archived on the server associated with each channel participant receiving the message, which enables clients to always retrieve messages from the clients MAM archive. Other channel nodes MAY be archived.
MIX channel nodes MAY be archived. In order to provide a service equivalent to MUC, it is necessary to archive messages sent to the channel. It is anticipated the most MIX services will archive at least messages using MAM.
</p>
<section3 topic="Archive of Messages" anchor="use-mam-messages">
<p>
@ -1254,10 +1255,11 @@
</section3>
<section3 topic="Retrieving Messages" anchor="use-mam-retrieve">
<p>
Clients will retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client.
The client's local server MAY archive messages and advertise this capability as specified in &xep0405;. If this is done,
clients MUST retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client.
</p>
<p>
Messages can also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. It can also be useful for new channel participants to access the historical archives.
Messages can also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. This enables new channel participants to access the historical archives.
</p>
</section3>
<section3 topic="MAM Use with other Channel Nodes" anchor="use-mam-other-nodes">
@ -1273,7 +1275,7 @@
<section3 topic='Checking For Permission To Create a Channel' anchor='usecase-admin-check-create'>
<p>
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:core:0#create-channel' feature is returned, the user is able to create a channel.
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:core:1#create-channel' feature is returned, the user is able to create a channel.
</p>
<example caption="Client determines Capability to Create a Channel" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
@ -1292,29 +1294,29 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='urn:xmpp:mix:core:0#create-channel'>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mix:core:1#create-channel'>
</query>
</iq>
]]></example>
</section3>
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
<p>
A client creates a channel by sending a simple request to the MIX service. A channel is always created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:core:0' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name. This attribute specifies the value that will be used in the LHS of the JID for the MIX channel.
A client creates a channel by sending a simple request to the MIX service. A channel is always created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:core:1' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name. This attribute specifies the value that will be used in the LHS of the JID for the MIX channel.
</p>
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create channel='coven' xmlns='urn:xmpp:mix:core:0'/>
<create channel='coven' xmlns='urn:xmpp:mix:core:1'/>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:core:0'/>
<create channel='coven' xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
@ -1334,14 +1336,14 @@
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create xmlns='urn:xmpp:mix:core:0'/>
<create xmlns='urn:xmpp:mix:core:1'/>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='A1B2C345' xmlns='urn:xmpp:mix:core:0'/>
<create channel='A1B2C345' xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
</section3>
@ -1352,7 +1354,7 @@
MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX service; This is specified in MIX-ADMIN. Where a channel is created for ad hoc use, it MAY be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.
</p>
<p>
The destroy operation is encoded as a &lt;destroy/&gt; child element of an &lt;iq/&gt; element. The &lt;destroy/&gt; element is qualified by the 'urn:xmpp:mix:core:0' namespace. The &lt;destroy/&gt; element MUST have a 'channel' attribute to specify the channel to be destroyed.
The destroy operation is encoded as a &lt;destroy/&gt; child element of an &lt;iq/&gt; element. The &lt;destroy/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The &lt;destroy/&gt; element MUST have a 'channel' attribute to specify the channel to be destroyed.
A client destroys a channel using a simple set operation, as shown in the following example.
</p>
<example caption="Client Destroys a Channel" ><![CDATA[
@ -1360,7 +1362,7 @@
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<destroy channel='coven' xmlns='urn:xmpp:mix:core:0'/>
<destroy channel='coven' xmlns='urn:xmpp:mix:core:1'/>
</iq>
<iq from='mix.shakespeare.example'

31
xep-0405.xml
View File

@ -38,11 +38,20 @@
<shortname>MIX-PAM</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.4.0</version>
<date>2019-03-19</date>
<initials>sek</initials>
<remark>
Make Archiving Optional;
Bump namespace to pam:1;
</remark>
</revision>
<revision>
<version>0.3.1</version>
<date>2019-01-13</date>
<initials>lnj (Editor: jsc)</initials>
<remark>Whitespace changes and XML syntax fixes</remark>
<remark>White space changes and XML syntax fixes</remark>
</revision>
<revision>
<version>0.3.0</version>
@ -186,7 +195,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section2 topic="Client Determines MIX Capability of Client's Server" anchor="user-server-client-capability">
<p>
Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:0' feature.
Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:1' feature. In addition to this the server MAY advertize the 'urn:xmpp:mix:pam:1#archive' feature, which shows that the local server archives MIX messages.
</p>
<example caption="Client Determines MIX Capability for Server Account"><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
@ -199,7 +208,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:mix:pam:0'/>
<feature var='urn:xmpp:mix:pam:1'/>
<feature var='urn:xmpp:mix:pam:1:archive'/>
</query>
</iq>
]]></example>
@ -222,7 +232,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in &xep0369;. &xep0369; specifies how the join command works, and so this specification considers only the wrapping and client actions.
The &lt;client-join/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-join/&gt; element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being joined is specified by a 'channel' attribute in the &lt;client-join/&gt; element, which is used by the server to correctly address the join. The &lt;join&gt; is specified in &xep0369; and is a child element of &lt;client-join/&gt;.
The &lt;client-join/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-join/&gt; element is qualified by the 'urn:xmpp:mix:pam:1' namespace. The channel being joined is specified by a 'channel' attribute in the &lt;client-join/&gt; element, which is used by the server to correctly address the join. The &lt;join&gt; is specified in &xep0369; and is a child element of &lt;client-join/&gt;.
</p>
<example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
@ -230,7 +240,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-join xmlns='urn:xmpp:mix:pam:0' channel='coven@mix.shakespeare.example'>
<client-join xmlns='urn:xmpp:mix:pam:1' channel='coven@mix.shakespeare.example'>
<join xmlns='urn:xmpp:mix:core:0'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
@ -285,7 +295,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-join xmlns='urn:xmpp:mix:pam:0'>
<client-join xmlns='urn:xmpp:mix:pam:1'>
<join xmlns='urn:xmpp:mix:core:0'
jid='123456#coven@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
@ -308,7 +318,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section2 topic='Leaving a Channel' anchor='usecase-user-leaving'>
<p>Users generally remain in a channel for an extended period of time. The process for leaving a MIX channel is specified in &xep0369;. When a user desires to leave a channel, it will issue a client-leave request to the local server.
The &lt;client-leave/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-leave/&gt; element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being left is specified by a 'channel' attribute in the &lt;client-leave/&gt; element, which is used by the server to correctly address the join. The &lt;leave&gt; is specified in &xep0369; and is a child element of &lt;client-leave/&gt;.
The &lt;client-leave/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-leave/&gt; element is qualified by the 'urn:xmpp:mix:pam:1' namespace. The channel being left is specified by a 'channel' attribute in the &lt;client-leave/&gt; element, which is used by the server to correctly address the join. The &lt;leave&gt; is specified in &xep0369; and is a child element of &lt;client-leave/&gt;.
This shown in the following example.</p>
@ -317,7 +327,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-leave xmlns='urn:xmpp:mix:pam:0'
<client-leave xmlns='urn:xmpp:mix:pam:1'
channel='coven@mix.shakespeare.example'>
<leave xmlns='urn:xmpp:mix:core:0'/>
</client-leave>
@ -360,7 +370,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-leave xmlns='urn:xmpp:mix:pam:0'>
<client-leave xmlns='urn:xmpp:mix:pam:1'>
<leave xmlns='urn:xmpp:mix:core:0'/>
</client-leave>
</iq>
@ -514,7 +524,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section2 topic="MAM Archive Support" anchor="usecase-mam">
<p>
Archive of MIX channel messages is done by the participant's server. Where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that the messages will be available in the local archive and can be picked up by clients when they come online.
Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:1#archive' feature. If archive is provided it MUST always be used, so that
where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online.
</p>
</section2>

8
xep-0415.xml
View File

@ -43,7 +43,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>REsource LOcation And Discovery (RELOAD) (RFC6940) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.</p>
<p>REsource LOcation And Discovery (RELOAD) (&rfc6940;) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.</p>
<p>The XMPP Usage involves two basic functions:</p>
<ol>
<li><strong>Address Location</strong>: XMPP clients can use the RELOAD data storage functionality to store a mapping from their XMPP address to their Node-ID in the overlay and to retrieve the Node-ID of other clients.</li>
@ -82,13 +82,13 @@
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di><dt>RELOAD</dt><dd>REsource LOcation And Discovery (RFC6940) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.</dd></di>
<di><dt>RELOAD</dt><dd>REsource LOcation And Discovery (&rfc6940;) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.</dd></di>
<di><dt>Address Location</dt><dd>One or many RELOAD Node-IDs to which a peer-to-peer connection can be established in order to contact an owner of the XMPP address.</dd></di>
</dl>
</section1>
<section1 topic='Storing an Address Location' anchor='addr-loc'>
<section2 topic='Overview' anchor='addr-loc-overview'>
<p>In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of RFC6940).</p>
<p>In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of &rfc6940;).</p>
<p>As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".</p>
<p>RELOAD peers can store two kinds of XMPP mappings,</p>
<ul>
@ -236,7 +236,7 @@
<tr>
<td>XMPP-LOCATION</td>
<td>0x5</td>
<td>XEP-XOR</td>
<td>XEP-0415</td>
</tr>
</table>
</section2>

14
xep-0416.xml
View File

@ -46,7 +46,7 @@
<dl>
<di><dt>E2E encryption</dt><dd>For end-to-end encryption, XMPP clients may use certificates to mutually identify each other, i.e. check that the cryptographic key belongs to this exact XMPP address.</dd></di>
<di><dt>External services</dt><dd>An XMPP server may authenticate users of other servers at its local services, such as an HTTP Upload component (&xep0363;), e.g. for granting file uploads, or a TURN server (&rfc5766;).</dd></di>
<di><dt>XMPP Usage of RELOAD</dt><dd>XMPP entities attached to the XOR overlay (XEP-XOR) are supposed to use certificates for mutual authentication.</dd></di>
<di><dt>XMPP Usage of RELOAD</dt><dd>XMPP entities attached to the XOR overlay (XEP-0415) are supposed to use certificates for mutual authentication.</dd></di>
<di><dt>SPAM protection</dt><dd>Since certificate authorities are required to be Sybil resistant (XEP-EAX-CAR), a spammer is limited in ability to create accounts massively. Thus it is expected that SPAM dissemination will fall to negligible levels.</dd></di>
<di><dt>Registration delegation</dt><dd>XMPP accounts registration typically creates a huge burden for operators of public servers. An operator may want to delegate a registration of accounts of its own server to a trusted CA. The CA will validate the users' identities and will issue certificates for them. The users can use these certificates in c2s SASL EXTERNAL authentication at the operator's server as well as for e2e authentication with other entities.</dd></di>
</dl>
@ -84,7 +84,7 @@
<section2 topic='General Requirements' anchor='gen-req'>
<ol>
<li>The leaf certificate MUST be compliant with c2s SASL EXTERNAL authentication (&rfc6120;, &xep0178;).</li>
<li>The leaf certificate MUST be compliant with RELOAD authentication (RFC6940).</li>
<li>The leaf certificate MUST be compliant with RELOAD authentication (&rfc6940;).</li>
</ol>
</section2>
<section2 topic='Certificate Requirements' anchor='cert-req'>
@ -100,11 +100,11 @@
<li>The certificate MUST NOT contain a basicConstraints extension with the cA boolean set to TRUE.</li>
<li>The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.</li>
<li>The certificate MUST possess a single XMPP address represented as an XmppAddr as specified under Section 13.7.1.4 of &rfc6120;.</li>
<li>The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of RFC6940 encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.</li>
<li>The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of &rfc6940; encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.</li>
<li>If the XMPP address doesn't contain non-ASCII characters, it MUST be encoded in the SubjectAltName field as rfc822Name type.</li>
</ol>
<p>Note that the rules for leaf certificates comply with the rules defined for client certificates under Sections 13.7.1.1 and 13.7.1.4 of &rfc6120;. Thus they can be used for c2s SASL EXTERNAL authentication.</p>
<p>The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.</p>
<p>The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-0415) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.</p>
<p>The following rules apply to domain-associated certificates:</p>
<ol>
<li>The certificate MUST contain a keyUsage extension with the keyCertSign bit set.</li>
@ -134,15 +134,15 @@
</section1>
<section1 topic='Root Certificates Discovery' anchor='root-cert-disco'>
<p>An XMPP entity MAY maintain its own list of root certificates. However, in practice it's convenient to retrieve this list from a trusted source. For example, several organizations in the Internet maintain and provide such lists for certificates verification in the Web. This section specifies how the list of root certificates can be retrieved for the purpose of e2e authentication in XMPP.</p>
<p>Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of RFC6940). The root certificates are PEM-encoded (RFC7468) with encapsulation boundaries removed and are included in &lt;root-cert/&gt; elements of the Overlay Configuration.</p>
<p>In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (RFC7232).</p>
<p>Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of &rfc6940;). The root certificates are PEM-encoded (&rfc7468;) with encapsulation boundaries removed and are included in &lt;root-cert/&gt; elements of the Overlay Configuration.</p>
<p>In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (&rfc7232;).</p>
<p>Further versions of this specification MAY extend the Overlay Configuration with new XML elements.</p>
</section1>
<section1 topic='Leaf Certificates Discovery' anchor='leaf-cert-disco'>
<p>An XMPP entity MAY want to publish its certificate so other XMPP entities MAY retrieve it. The method to accomplish this depends on the usage:</p>
<ul>
<li>In the case of an ordinary XMPP usage (&rfc6120;) a special PEP node (&xep0163;) is used as specified in XEP-EAX-SIGN.</li>
<li>In the case of XMPP Usage of RELOAD (XEP-XOR) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of RFC6940).</li>
<li>In the case of XMPP Usage of RELOAD (XEP-0415) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of &rfc6940;).</li>
</ul>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>

5
xep.ent
View File

@ -671,7 +671,10 @@ THE SOFTWARE.
<!ENTITY rfc6763 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6763'>RFC 6763</link></span> <note>RFC 6763: DNS-Based Service Discovery &lt;<link url='http://tools.ietf.org/html/rfc6763'>http://tools.ietf.org/html/rfc6763</link>&gt;.</note>" >
<!ENTITY rfc6797 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6797'>RFC 6797</link></span> <note>RFC 6797: HTTP Strict Transport Security (HSTS) &lt;<link url='http://tools.ietf.org/html/rfc6797'>http://tools.ietf.org/html/rfc6797</link>&gt;.</note>" >
<!ENTITY rfc6920 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6920'>RFC 6920</link></span> <note>RFC 6920: Naming Things with Hashes &lt;<link url='http://tools.ietf.org/html/rfc6920'>http://tools.ietf.org/html/rfc6920</link>&gt;.</note>" >
<!ENTITY rfc6940 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6940'>RFC 6940</link></span> <note>RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol &lt;<link url='http://tools.ietf.org/html/rfc6940'>http://tools.ietf.org/html/rfc6940</link>&gt;.</note>" >
<!ENTITY rfc7081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7081'>RFC 7081</link></span> <note>RFC 7081: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc7081'>http://tools.ietf.org/html/rfc7081</link>&gt;.</note>" >
<!ENTITY rfc7232 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7232'>RFC 7232</link></span> <note>RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests &lt;<link url='http://tools.ietf.org/html/rfc7232'>http://tools.ietf.org/html/rfc7232</link>&gt;.</note>" >
<!ENTITY rfc7468 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7468'>RFC 7468</link></span> <note>RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures &lt;<link url='http://tools.ietf.org/html/rfc7468'>http://tools.ietf.org/html/rfc7468</link>&gt;.</note>" >
<!ENTITY rfc7469 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7469'>RFC 7469</link></span> <note>RFC 7469: Public Key Pinning Extension for HTTP &lt;<link url='http://tools.ietf.org/html/rfc7469'>http://tools.ietf.org/html/rfc7469</link>&gt;.</note>" >
<!ENTITY rfc7519 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7519'>RFC 7519</link></span> <note>RFC 7519: JSON Web Token (JWT) &lt;<link url='http://tools.ietf.org/html/rfc7519'>http://tools.ietf.org/html/rfc7519</link>&gt;.</note>" >
<!ENTITY rfc7572 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7572'>RFC 7572</link></span> <note>RFC 7572: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging &lt;<link url='http://tools.ietf.org/html/rfc7572'>http://tools.ietf.org/html/rfc7572</link>&gt;.</note>" >
@ -1548,3 +1551,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!ENTITY xep0412 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0412.html'>XMPP Compliance Suites 2019 (XEP-0412)</link></span> <note>XEP-0412: XMPP Compliance Suites 2019 &lt;<link url='https://xmpp.org/extensions/xep-0412.html'>https://xmpp.org/extensions/xep-0412.html</link>&gt;.</note>" >
<!ENTITY xep0413 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0413.html'>Order-By (XEP-0413)</link></span> <note>XEP-0413: Order-By &lt;<link url='https://xmpp.org/extensions/xep-0413.html'>https://xmpp.org/extensions/xep-0413.html</link>&gt;.</note>" >
<!ENTITY xep0414 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0414.html'>Cryptographic Hash Function Recommendations for XMPP (XEP-0414)</link></span> <note>XEP-0414: Cryptographic Hash Function Recommendations for XMPP &lt;<link url='https://xmpp.org/extensions/xep-0414.html'>https://xmpp.org/extensions/xep-0414.html</link>&gt;.</note>" >
<!ENTITY xep0415 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0415.html'>XMPP Over RELOAD (XEP-0415)</link></span> <note>XEP-0415: XMPP Over RELOAD (XOR) &lt;<link url='https://xmpp.org/extensions/xep-0415.html'>https://xmpp.org/extensions/xep-0415.html</link>&gt;.</note>" >
<!ENTITY xep0416 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0416.html'>E2E Authentication in XMPP (XEP-0416)</link></span> <note>XEP-0416: E2E Authentication in XMPP &lt;<link url='https://xmpp.org/extensions/xep-0416.html'>https://xmpp.org/extensions/xep-0416.html</link>&gt;.</note>" >