aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--inbox/colors.xml282
-rw-r--r--inbox/jet.xml114
-rwxr-xr-xtools/deferrals.py74
-rwxr-xr-xtools/send-updates.py22
-rw-r--r--tools/xeplib.py5
-rw-r--r--xep-0001.xml4
-rw-r--r--xep-0045.xml9
-rw-r--r--xep-0065.xml12
-rw-r--r--xep-0234.xml2
-rw-r--r--xep-0278.xml103
-rw-r--r--xep-0319.xml16
-rw-r--r--xep-0327.xml8
-rw-r--r--xep-0329.xml8
-rw-r--r--xep-0332.xml8
-rw-r--r--xep-0333.xml8
-rw-r--r--xep-0337.xml8
-rw-r--r--xep-0338.xml8
-rw-r--r--xep-0339.xml8
-rw-r--r--xep-0340.xml8
-rw-r--r--xep-0341.xml8
-rw-r--r--xep-0342.xml8
-rw-r--r--xep-0343.xml8
-rw-r--r--xep-0344.xml8
-rw-r--r--xep-0345.xml8
-rw-r--r--xep-0346.xml8
-rw-r--r--xep-0347.xml8
-rw-r--r--xep-0348.xml8
-rw-r--r--xep-0349.xml8
-rw-r--r--xep-0350.xml8
-rw-r--r--xep-0351.xml8
-rw-r--r--xep-0353.xml8
-rw-r--r--xep-0354.xml8
-rw-r--r--xep-0355.xml8
-rw-r--r--xep-0356.xml8
-rw-r--r--xep-0358.xml8
-rw-r--r--xep-0360.xml8
-rw-r--r--xep-0361.xml8
-rw-r--r--xep-0362.xml8
-rw-r--r--xep-0365.xml8
-rw-r--r--xep-0367.xml8
-rw-r--r--xep-0370.xml8
-rw-r--r--xep-0371.xml8
-rw-r--r--xep-0372.xml8
-rw-r--r--xep-0373.xml8
-rw-r--r--xep-0376.xml8
-rw-r--r--xep-0377.xml8
-rw-r--r--xep-0378.xml8
-rw-r--r--xep-0384.xml85
48 files changed, 889 insertions, 127 deletions
diff --git a/inbox/colors.xml b/inbox/colors.xml
new file mode 100644
index 0000000..cd1755c
--- /dev/null
+++ b/inbox/colors.xml
@@ -0,0 +1,282 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE xep SYSTEM 'xep.dtd' [
+ <!ENTITY % ents SYSTEM 'xep.ent'>
+%ents;
+ <!ENTITY rgblind "<em>Red/Green-Blindness</em>">
+ <!ENTITY bblind "<em>Blue-Blindness</em>">
+ <!ENTITY cvd "Color Vision Deficiency">
+ <!ENTITY cvds "Color Vision Deficiencies">
+]>
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
+<xep>
+<header>
+ <title>Consistent Color Generation</title>
+ <abstract>This specification provides a set of algorithms to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All entities adhering to this specification generate the same color for the same string, which provides a consistent user experience across platforms.</abstract>
+ &LEGALNOTICE;
+ <number>xxxx</number>
+ <status>ProtoXEP</status>
+ <type>Standards Track</type>
+ <sig>Standards</sig>
+ <approver>Council</approver>
+ <dependencies></dependencies>
+ <supersedes/>
+ <supersededby/>
+ <shortname>colors</shortname>
+ <author>
+ <firstname>Jonas</firstname>
+ <surname>Wielicki</surname>
+ <email>jonas@wielicki.name</email>
+ <jid>jonas@wielicki.name</jid>
+ </author>
+ <revision>
+ <version>0.0.1</version>
+ <date>2017-09-14</date>
+ <initials>jwi</initials>
+ <remark><p>First draft.</p></remark>
+ </revision>
+</header>
+<section1 topic='Introduction' anchor='intro'>
+ <p>Colors provide a valuable visual cue to recognize text. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities.</p>
+</section1>
+<section1 topic='Requirements' anchor='reqs'>
+ <p>The color generation mechanism should provide the following features:</p>
+ <ul>
+ <li>Consistent generation of color across all platforms depending solely on the identifier used as input for the algorithm.</li>
+ <li>The system should be reasonably fast; it must be possible to, for example, apply it to all roster entries even of very large rosters in reasonable amount of time.</li>
+ <li>It must be able to provide decent contrast on any background.</li>
+ <li>The implementation should be stateless and not be complex.</li>
+ <li>A fallback path for users with common types of &cvds; must be provided.</li>
+ <li>A fallback path for systems which can only use colors from a restricted palette must be provided.</li>
+ </ul>
+</section1>
+<section1 topic='Use Cases' anchor='usecases'>
+ <section2 topic='Generating a color' anchor='usecase-textcolor'>
+ <p>To generate a color from a string of text, the follownig algorithms are applied in order:</p>
+ <ol>
+ <li><link url='#algorithm-angle'>Generate an angle in the CbCr plane from the text</link>.</li>
+ <li>If enabled, <link url='#algorithm-cvd'>apply configured corrections for &cvds;</link>.</li>
+ <li><link url='#algorithm-cbcr'>Convert the angle to a CbCr pair</link>.</li>
+ <li>If the output device only supports a small palette of colors, <link url='#algorithm-mappalette'>map the CbCr value to the closest palette color</link>.</li>
+ <li>If the output device supports RGB output, <link url='#algorithm-rgb'>convert the CbCr pair to an RGB triple</link>.</li>
+ </ol>
+ </section2>
+ <section2 topic='Adding colors to participants of a conversation' anchor='usecase-nickcolor'>
+ <p>Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.</p>
+ <p>In such cases, the color SHOULD be generated as described in the <link url='#usecase-textcolor'>Generating a color</link> section. The input used SHOULD be, in descending order of preference, (a) the name assigned in the roster, (b) the nickname from the conversation, (c) the bare JID.</p>
+ </section2>
+ <section2 topic='Auto-Generating Avatars' anchor='usecase-avatar'>
+ <p>Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;).</p>
+ <p>In such cases, auto-generating an avatar SHOULD happen as follows:</p>
+ <ol>
+ <li>Obtain a name for the contact, in descending order of preference, (a) from the roster, (b) by using the nickname from the conversation, (c) by using the bare JID.</li>
+ <li>Generate a color as described in the <link url='#usecase-textcolor'>Generating a color</link> section.</li>
+ <li>Fill an implementation-defined background shape with that color.</li>
+ <li>Render the first character of the name in white or black centered on the square.</li>
+ </ol>
+ </section2>
+</section1>
+<section1 topic='Business Rules' anchor='rules'>
+ <ul>
+ <li>Implementations MUST allow the user to turn off any colorization completely.</li>
+ <li>Implementations MUST implement the &cvd; profiles and MUST allow the user to choose any of these profiles or to disable the correction.</li>
+ <li>Implementations MUST NOT share the &cvd; correction settings with other entities.</li>
+ </ul>
+</section1>
+<section1 topic='Algorithms' anchor='algorithm'>
+ <section2 topic='Angle generation' anchor='algorithm-angle'>
+ <p>Input: An identifier, encoded as octets of UTF-8 (&rfc3269;).</p>
+ <p>Output: Angle in the CbCr plane.</p>
+ <p>Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color.</p>
+ <ol>
+ <li>Run the input through CRC32 as defined by zlib (TODO: add citation).</li>
+ <li>Take the lower 16 bits and XOR them with the upper 16 bits.</li>
+ <li>Divide the value by 65535 (use float division) and multiply it by 2&#960; (two Pi).</li>
+ </ol>
+ </section2>
+ <section2 topic='Corrections for &cvds;' anchor='algorithm-cvd'>
+ <p>Input: Angle in the CbCr plane.</p>
+ <p>Output: Angle in the CbCr plane.</p>
+ <p>Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;.</p>
+ <section3 topic='Red/Green-blindness' anchor='algorithm-cvd-rg'>
+ <p>Divide the angle by two.</p>
+ </section3>
+ <section3 topic='Blue-blindness' anchor='algorithm-cvd-b'>
+ <p>Divide the angle by two and add &#960;/2 (half Pi).</p>
+ </section3>
+ </section2>
+ <section2 topic='CbCr generation' anchor='algorithm-cbcr'>
+ <p>Input: Angle in the CbCr plane, from the previous algorithm.</p>
+ <p>Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5.</p>
+ <p>Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr:</p>
+ <code><![CDATA[float cr = sin(angle);
+float cb = cos(angle);
+float factor;
+if (abs(cr) > abs(cb)) {
+ factor = 0.5 / abs(cr);
+} else {
+ factor = 0.5 / abs(cb);
+}
+cb = cb * factor;
+cr = cr * factor;
+]]></code>
+ </section2>
+ <section2 topic='CbCr to RGB' anchor='algorithm-rgb'>
+ <p>Input: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y.</p>
+ <p>Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.</p>
+ <p>Note: The recommended value for Y is 0.732. See <link url='#impl-gamma'>Gamma Correction</link> for a discussion on the choice of Y.</p>
+ <ol>
+ <li>Calculate r, g and b according to BT.601:<code><![CDATA[float r = 2*(1 - KR)*cr + y;
+float b = 2*(1 - KB)*cb + y;
+float g = (y - KR*r - KB*b)/KG;
+]]></code></li>
+ <li>Clip the values of r, g and b to the range from 0 to 1.</li>
+ </ol>
+ </section2>
+ <section2 topic='Adapting the Color for specific Background Colors' anchor='algorithm-bg'>
+ <p>Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each.</p>
+ <p>Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1.</p>
+ <ol>
+ <li>Invert the background color by subtracting the individual channels from 1 each:
+ <code><![CDATA[
+rb = 1-rb;
+gb = 1-gb;
+bb = 1-bb;]]></code></li>
+ <li>Mix the inverted background with the color to adapt, using a mixing factor of 0.2:
+ <code><![CDATA[
+rc = 0.2*rb + 0.8*ri;
+gc = 0.2*gb + 0.8*gi;
+bc = 0.2*bb + 0.8*bi;]]></code></li>
+ </ol>
+ </section2>
+ <section2 topic='RGB to YCbCr' anchor='algorithm-rgb2cbcr'>
+ <p>Input: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.</p>
+ <p>Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y.</p>
+ <p>Calculate Y, Cb and Cr according to BT.601:</p>
+ <code><![CDATA[
+y = KR*r + (1 - KR - KB)*g + KB*b;
+cb = (b - y) / (1 - KB) / 2
+cr = (r - y) / (1 - KR) / 2
+]]></code>
+ </section2>
+ <section2 topic='Conversion of an RGB color palette to a CbCr color palette' anchor='algorithm-genpalette'>
+ <p>Input: A set of RGB colors (each component from 0 to 1).</p>
+ <p>Output: A mapping from CbCr pairs (each component from -0.5 to 0.5) to RGB colors.</p>
+ <p>Note: when the algorithm finishes, the mapping maps CbCr values (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness.</p>
+ <ol>
+ <li>Create an empty mapping M which maps from pairs of CbCr values to quadruples of Y, R, G and B.</li>
+ <li>For each color R, G, B from the input palette:
+ <ol>
+ <li>Calculate Y, Cb and Cr from R, G, B as described in <link url='#algorithm-rgb2cbcr'>RGB to YCbCr</link>.</li>
+ <li>Round Cb and Cr to two decimal places as Cb' and Cr'.</li>
+ <li>If the (Cb', Cr') pair is not in the mapping M yet, or if the Y value of the existing entry is farther away from 0.732 than the new Y value, put the Y, R, G, and B values as value for the (Cb', Cr') pair into the mapping.</li>
+ </ol>
+ </li>
+ <li>Strip the Y values from the values of mapping M.</li>
+ <li>Return M as the result of the algorithm.</li>
+ </ol>
+ </section2>
+ <section2 topic='Mapping of a CbCr color to closest palette color' anchor='algorithm-mappalette'>
+ <p>Input: A set of colors (the palette) as tuples of Cbp and Crp and a color to map to the closest palette color as Cb and Cr value.</p>
+ <p>Output: A palette color as Cbr and Crr values.</p>
+ <ol>
+ <li>For each color as pair Cbp, Crp in the palette, calculate the distance metric: <code>D = sqrt((Cbp-Cb)*(Cbp-Cb) + (Crp-Cr)*(Crp-Cr))</code>.</li>
+ <li>Pick the palette color Cbp, Crp with the smallest distance metric D as result color Cbr, Crr.</li>
+ </ol>
+ <p>Note: the distance metric is simply the euclidian distance in the CbCr plane.</p>
+ </section2>
+ <section2 topic='Test Vectors' anchor='algorithm-testvector'>
+ <p>This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes (&apos;). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, and the Cb, Cr, Red, Green, and Blue values.</p>
+ <section3 topic='No &cvd; correction' anchor='algorithm-testvector-no-cvd'>
+ <code><![CDATA[
+text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',2.099189,-0.291880,0.500000,1.000,0.475,0.215
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',5.830846,0.500000,-0.242972,0.391,0.733,1.000
+'😺','f09f98ba',4.312757,-0.211180,-0.500000,0.031,1.000,0.358]]></code>
+ </section3>
+ <section3 topic='With Red/Green-blindess correction' anchor='algorithm-testvector-cvd-redgreen'>
+ <code><![CDATA[text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',1.049594,0.287079,0.500000,1.000,0.276,1.000
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',2.915423,-0.500000,0.115053,0.893,0.822,0.000
+'😺','f09f98ba',2.156378,-0.331588,0.500000,1.000,0.489,0.144]]></code>
+ </section3>
+ <section3 topic='With Blue-blindess correction' anchor='algorithm-testvector-cvd-blue'>
+ <code><![CDATA[
+text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',2.620391,-0.500000,0.287079,1.000,0.699,0.000
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',4.486219,-0.115053,-0.500000,0.031,1.000,0.528
+'😺','f09f98ba',3.727175,-0.500000,-0.331588,0.267,1.000,0.000]]></code>
+ </section3>
+ <section3 topic='Mapping to 216 color palette' anchor='algorithm-testvector-palette'>
+ <p>The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 216 colors). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.</p>
+ <section4 topic='No &cvd; correction' anchor='algorithm-testvector-palette-no-cvd'>
+ <code><![CDATA[
+text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',2.099189,-0.291880,0.500000,1.000,0.200,0.000
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',5.830846,0.500000,-0.242972,0.000,0.200,1.000
+'😺','f09f98ba',4.312757,-0.211180,-0.500000,0.000,1.000,0.200]]></code>
+ </section4>
+ <section4 topic='With Red/Green-blindess correction' anchor='algorithm-testvector-palette-cvd-redgreen'>
+ <code><![CDATA[
+text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',1.049594,0.287079,0.500000,1.000,0.000,0.800
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',2.915423,-0.500000,0.115053,1.000,1.000,0.000
+'😺','f09f98ba',2.156378,-0.331588,0.500000,1.000,0.200,0.000]]></code>
+ </section4>
+ <section4 topic='With Blue-blindess correction' anchor='algorithm-testvector-palette-cvd-blue'>
+ <code><![CDATA[
+text,hextext,angle,cb,cr,r,g,b
+'Romeo','526f6d656f',2.620391,-0.500000,0.287079,1.000,0.600,0.000
+'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',4.486219,-0.115053,-0.500000,0.000,1.000,0.400
+'😺','f09f98ba',3.727175,-0.500000,-0.331588,0.200,1.000,0.000]]></code>
+ </section4>
+ </section3>
+ </section2>
+</section1>
+<section1 topic='Implementation Notes' anchor='impl'>
+ <section2 topic='Gamma Correction' anchor='impl-gamma'>
+ <p>An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5.</p>
+ <p>Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations SHOULD instead use the algorithm described in <link url='#algorithm-bg'>Adapting the Color for specific Background Colors</link> for that.</p>
+ </section2>
+</section1>
+<section1 topic='Accessibility Considerations' anchor='access'>
+ <p>As outlined above, implementations MUST offer the &rgblind; and &bblind; corrections as defined in the <link url='#algorithm-cvd'>Corrections for &cvds;</link> section. Users MUST be allowed to choose between:</p>
+ <ul>
+ <li>disabling all corrections (skip the Corrections for &cvds; step entirely),</li>
+ <li>applying one of the &cvd; correction profiles and</li>
+ <li>disabling colorization altogether.</li>
+ </ul>
+ <p>The last option is important for users with monochromatic view.</p>
+ <p>Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.</p>
+</section1>
+<section1 topic='Security Considerations' anchor='security'>
+ <p>This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those.</p>
+ <p>Due to the limited set of distinguishable colors, possible &cvds; and/or use of palettes, entities MUST NOT rely on colors being unique in any context.</p>
+</section1>
+<section1 topic='Design Considerations' anchor='design'>
+ <p>This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected.</p>
+ <section2 topic='Other variants of the YCbCr color space' anchor='design-other-ycbcr'>
+ <p>The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as BT.601 does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain.</p>
+ </section2>
+ <section2 topic='Hue-Saturation-Value/Lightness color space' anchor='design-hsv'>
+ <p>The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain.</p>
+ </section2>
+ <section2 topic='Palette-based and context-aware coloring' anchor='design-context'>
+ <p>Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen.</p>
+ <p>There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose.</p>
+ <p>In addition, more state needs to be taken into account, increasing the complexity of choosing a color.</p>
+ </section2>
+ <section2 topic='Choice of mixing function in angle generation' anchor='design-mixing'>
+ <p>This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, a CRC32 sum is used.</p>
+ <p>An alternative, which may yield better distribution of colors, would have been to use a cryptographic hash function. However, the performance and implementation cost for a cryptographic hash function is considerable compared with a simple CRC32, especially on small (less than 1 kiB) inputs.</p>
+ </section2>
+</section1>
+<section1 topic='IANA Considerations' anchor='iana'>
+ <p>This document requires no interaction with &IANA;. </p>
+</section1>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+ <p>This document requires no interaction with the &REGISTRAR;. </p>
+</section1>
+<section1 topic='Acknowledgements' anchor='acknowledgements'>
+ <p>Thanks to Daniel Gultsch, Georg Lukas, and Tobias Markmann.</p>
+</section1>
+</xep>
diff --git a/inbox/jet.xml b/inbox/jet.xml
index 3e1e064..ebcf9e1 100644
--- a/inbox/jet.xml
+++ b/inbox/jet.xml
@@ -8,7 +8,7 @@
<xep>
<header>
<title>Jingle Encrypted Transports</title>
- <abstract>This specification defines a method that allows to use established encryption schemes like OpenPGP or OMEMO for end-to-end encryption of Jingle transports.</abstract>
+ <abstract>This specification defines a method that allows to use established encryption schemes for end-to-end encryption of Jingle transports.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
@@ -73,23 +73,23 @@
<tr>
<td>Envelope Element</td>
<td>EE</td>
- <td>Output of an established end-to-end encryption methods when encrypting TS. Examples for such methods could be &xep0384; or &xep0374;.</td>
+ <td>Output element of an established end-to-end encryption method when encrypting TS.</td>
</tr>
</table>
</section1>
<section1 topic='Principle' anchor='principle'>
- <p>Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. Examples for suitable encryption sessions are &xep0384; and &xep0374;. This session is needed to transfer the Transport Secret from Romeo to Juliet.</p>
+ <p>Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. This session is needed to transfer the Transport Secret from Romeo to Juliet.</p>
<p>When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable <link url='#ciphers'>ciphers</link> from which Romeo might choose. TK and IV are serialized to create the transport secret (TS).</p>
<p>Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element.</p>
- <p>When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged.</p>
+ <p>When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended.</p>
</section1>
<section1 topic='Encrypted Jingle File Transfer using JET' anchor='jft'>
<p>&xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed.</p>
<p>In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request.</p>
- <section2 topic='File offer'>
- <p>In this scenario Romeo wants to send an encrypted text file over to Juliet. He chooses to use their existing &xep0384; session to do so. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos OMEMO session with Juliet.</p>
- <p>The resulting OMEMO element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.</p>
+ <section2 topic='File Offer'>
+ <p>In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet.</p>
+ <p>The resulting envelope element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.</p>
<example caption="Romeo initiates an encrypted file offer"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='nzu25s8'
@@ -125,13 +125,8 @@
<security xmlns='urn:xmpp:jingle:jet:0'
name='a-file-offer'
cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding'
- type='urn:xmpp:omemo:0'>
- <encrypted xmlns='urn:xmpp:omemo:0'>
- <header sid='27183'>
- <key rid='31415'>BASE64ENCODED...</key>
- <key rid='12321'>BASE64ENCODED...</key>
- <iv>BASE64ENCODED...</iv>
- </header>
+ type='urn:xmpp:encryption:stub:0'>
+ <encrypted xmlns='urn:xmpp:encryption:stub:0'>
<payload>BASE64-ENCODED-ENCRYPTED-SECRET</payload>
</encrypted>
</security>
@@ -139,12 +134,12 @@
</jingle>
</iq>]]></example>
- <p>Juliet decrypts the OMEMO element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet.</p>
+ <p>Juliet decrypts the envelope element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet.</p>
<p>When Juliet received the file, she uses the TK and IV to decrypt the received file.</p>
</section2>
<section2 topic='File Request'>
- <p>Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet. In this example we assume, that Romeo and Juliet secured their communications using &xep0374;.</p>
+ <p>Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet.</p>
<example caption="Juliet initiates an encrypted file request"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='wsn361c3'
@@ -174,20 +169,64 @@
<security xmlns='urn:xmpp:jingle:jet:0'
name='a-file-request'
cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding'
- type='urn:xmpp:openpgp:0'>
- <signcrypt xmlns='urn:xmpp:openpgp:0'>
- <to jid='romeo@montague.example'/>
- <time stamp='2014-07-10T17:06:00+02:00'/>
- <rpad>f0rm1l4n4-mT8y33j!Y%fRSrcd^ZE4Q7VDt1L%WEgR!kv</rpad>
- <payload>
- <body xmlns='jabber:client'>BASE64-ENCODED-ENCRYPTED-SECRET</body>
- </payload>
- </signcrypt>
+ type='urn:xmpp:encryption:stub:0'>
+ <encrypted xmlns='urn:xmpp:encryption:stub:0'>
+ <payload>BASE64-ENCODED-ENCRYPTED-SECRET</payload>
+ </encrypted>
+ </security>
+ </content>
+ </jingle>
+</iq>]]></example>
+ </section2>
+
+ <section2 topic='Encrypted Ranged Transfers'>
+ <p>&xep0234; defines a way for parties to request ranged transfers. This can be used to resume interrupted transfers etc. In case of an interrupted transfer, the receiving party might be able to decrypt parts of the received file. When requesting a resumption of the transfer, the recipient therefore can use the index of the last successfully decrypted byte of the file as offset in the ranged transfer. Since a resumed transfer takes place in a new session, the old transport secret might no longer be available to either party. For that reason the receiver creates a new TS for the session-initiation. The sending party then encrypts and sends only the requested parts of the file.</p>
+ <example caption="Romeo requests the resumption of an interrupted transfer using a fresh transport secret"><![CDATA[
+<iq from='romeo@montague.example/dr4hcr0st3lup4c'
+ id='wsn361c3'
+ to='juliet@capulet.example/yn0cl4bnw0yr3vym'
+ type='set'>
+ <jingle xmlns='urn:xmpp:jingle:1'
+ action='session-initiate'
+ initiator='romeo@montague.example/dr4hcr0st3lup4c'
+ sid='uj3b2'>
+ <content creator='initiator' name='restart' senders='responder'>
+ <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
+ <file>
+ <range offset='270336'/>
+ <hash xmlns='urn:xmpp:hashes:2'
+ algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
+ </file>
+ </description>
+ <transport xmlns='urn:xmpp:jingle:transports:s5b:1'
+ mode='tcp'
+ sid='vj3hs98y'>
+ <candidate cid='hft54dqy'
+ host='192.168.4.1'
+ jid='romeo@montague.example/dr4hcr0st3lup4c'
+ port='5086'
+ priority='8257636'
+ type='direct'/>
+ <candidate cid='hutr46fe'
+ host='24.24.24.1'
+ jid='romeo@montague.example/dr4hcr0st3lup4c'
+ port='5087'
+ priority='8258636'
+ type='direct'/>
+ </transport>
+ <security xmlns='urn:xmpp:jingle:jet:0'
+ name='restart'
+ cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding'
+ type='urn:xmpp:encryption:stub:0'>
+ <encrypted xmlns='urn:xmpp:encryption:stub:0'>
+ <payload>BASE64-ENCODED-ENCRYPTED-SECRET</payload>
+ </encrypted>
</security>
</content>
</jingle>
</iq>]]></example>
</section2>
+
</section1>
<section1 topic='Ciphers' anchor='ciphers'>
@@ -218,11 +257,32 @@
<p>The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.</p>
</section1>
+<section1 topic='Determining Support' anchor='support'>
+ <p>To advertise its support for the Jingle Encrypted Transports, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version, or extension of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:jet:0" for this version, or "urn:xmpp:jingle:jet-stub:0" for a stub encryption method &VNOTE;.</p>
+ <example caption="Service discovery information request"><![CDATA[
+<iq from='romeo@montague.example/dr4hcr0st3lup4c'
+ id='uw72g176'
+ to='juliet@capulet.example/yn0cl4bnw0yr3vym'
+ type='get'>
+ <query xmlns='http://jabber.org/protocol/disco#info'/>
+</iq>]]></example>
+ <example caption="Service discovery information response"><![CDATA[
+<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
+ id='uw72g176'
+ to='romeo@montague.example/dr4hcr0st3lup4c'
+ type='result'>
+ <query xmlns='http://jabber.org/protocol/disco#info'>
+ <feature var='urn:xmpp:jingle:jet:0'/>
+ <feature var='urn:xmpp:jingle:jet-stub:0'/>
+ </query>
+</iq>]]></example>
+ <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
+</section1>
+
<section1 topic='Security Considerations' anchor='security'>
<p>The initiator SHOULD NOT use the generated key TK as IV, but instead generate a seperate random IV.</p>
<p>Instead of falling back to unencrypted transfer in case something goes wrong, implementations MUST instead abort the Jingle session, informing the user.</p>
<p>IMPORTANT: This approach does not deal with metadata. In case of &xep0234;, an attacker with access to the sent stanzas can for example still see the name of the file and other information included in the &lt;file/&gt; element.</p>
- <p>When using OX as encryption method, clients might want to protect against replay attacks</p>
<p>The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks</p>
</section1>
@@ -236,7 +296,7 @@
</section1>
<section1 topic='TODO'>
<ul>
- <li>Service discovery</li>
+ <li>Split up the protocol into encryption method specific sub protocols (jet-omemo, jet-ox...)</li>
</ul>
</section1>
</xep>
diff --git a/tools/deferrals.py b/tools/deferrals.py
index 6674385..f2b70a1 100755
--- a/tools/deferrals.py
+++ b/tools/deferrals.py
@@ -1,4 +1,6 @@
#!/usr/bin/env python3
+import re
+
import xml.etree.ElementTree as etree
from datetime import datetime, timedelta
@@ -17,6 +19,51 @@ def get_deferred(accepted):
yield info
+EXPERIMENTAL_STATUS = "<status>Experimental</status>"
+DEFERRED_STATUS = "<status>Deferred</status>"
+REVISION_RE = re.compile(r"\s+<revision>")
+REVISION_TEMPLATE = """
+ <revision>
+ <version>{version}</version>
+ <date>{now:%Y-%m-%d}</date>
+ <initials>XEP Editor ({initials})</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>"""
+
+
+def defer_xep(number, last_version, initials):
+ filename = "xep-{:04d}.xml".format(number)
+ with open(filename, "r") as f:
+ xep_text = f.read()
+
+ if EXPERIMENTAL_STATUS not in xep_text:
+ raise ValueError("cannot find experimental status in XEP text")
+
+ # this is so incredibly evil ...
+ xep_text = xep_text.replace(EXPERIMENTAL_STATUS, DEFERRED_STATUS, 1)
+ revision_match = REVISION_RE.search(xep_text)
+
+ version = last_version.split(".")
+ if len(version) == 1:
+ version.append("1")
+ else:
+ version[1] = str(int(version[1]) + 1)
+ del version[2:]
+
+ xep_text = (
+ xep_text[:revision_match.start()] +
+ REVISION_TEMPLATE.format(
+ now=datetime.utcnow(),
+ version=".".join(version),
+ initials=initials,
+ ) + xep_text[revision_match.start():]
+ )
+
+ with open(filename, "w") as f:
+ f.write(xep_text)
+ f.flush()
+
+
def main():
import argparse
@@ -32,10 +79,18 @@ def main():
)
parser.add_argument(
- "-m", "--modify",
+ "-v", "--verbose",
+ help="Print additional metadata for deferred XEPs",
action="store_true",
default=False,
- help="Modify the XEP files in-place."
+ )
+
+ parser.add_argument(
+ "-m", "--modify",
+ default=False,
+ metavar="INITIALS",
+ help="Modify the to-be-deferred XEPs in-place and use the given "
+ "INITIALS in the remarks."
)
args = parser.parse_args()
@@ -50,7 +105,20 @@ def main():
deferred = list(get_deferred(accepted))
for deferred_info in deferred:
- print(deferred_info["number"])
+ if args.modify:
+ defer_xep(deferred_info["number"],
+ deferred_info["last_revision"]["version"],
+ args.modify)
+
+ if args.verbose:
+ print(
+ "XEP-{info[number]:04d}: {info[title]} "
+ "(last update {info[last_revision][date]:%Y-%m-%d})".format(
+ info=deferred_info
+ )
+ )
+ else:
+ print(deferred_info["number"])
if __name__ == "__main__":
diff --git a/tools/send-updates.py b/tools/send-updates.py
index 065e93b..de48907 100755
--- a/tools/send-updates.py
+++ b/tools/send-updates.py
@@ -68,6 +68,19 @@ Changelog:
URL: {url}"""
+MAIL_DEFER_TEMPLATE = """\
+XEP-{info[number]:04d} ({info[title]}) has been Deferred because of inactivity.
+
+Abstract:
+{info[abstract]}
+
+URL: {url}
+
+If and when a new revision of this XEP is published, its status will be \
+changed back to Experimental.
+"""
+
+
SUBJECT_NONPROTO_TEMPLATE = \
"{action.value}: XEP-{info[number]:04d} ({info[title]})"
@@ -86,6 +99,9 @@ def diff_infos(old, new):
return Action.PROTO
elif old["status"] is None:
return Action.NEW
+ elif (old["status"] == Status.DEFERRED and
+ new["status"] == Status.EXPERIMENTAL):
+ return Action.UPDATE
else:
return Action.fromstatus(new["status"])
@@ -152,6 +168,10 @@ def make_nonproto_mail(action, info):
),
}
+ body_template = MAIL_NONPROTO_TEMPLATE
+ if action == Action.DEFER:
+ body_template = MAIL_DEFER_TEMPLATE
+
mail = email.message.EmailMessage()
mail["Subject"] = SUBJECT_NONPROTO_TEMPLATE.format(**kwargs)
mail["XSF-XEP-Action"] = action.value
@@ -161,7 +181,7 @@ def make_nonproto_mail(action, info):
mail["XSF-XEP-Number"] = "{:04d}".format(info["number"])
mail["XSF-XEP-Url"] = kwargs["url"]
mail.set_content(
- wraptext(MAIL_NONPROTO_TEMPLATE.format(**kwargs)),
+ wraptext(body_template.format(**kwargs)),
"plain",
"utf-8",
)
diff --git a/tools/xeplib.py b/tools/xeplib.py
index 5a25004..93065f7 100644
--- a/tools/xeplib.py
+++ b/tools/xeplib.py
@@ -35,6 +35,7 @@ class Action(enum.Enum):
OBSOLETE = "OBSOLETED"
DEFER = "DEFERRED"
UPDATE = "UPDATED"
+ DEPRECATE = "DEPRECATED"
@classmethod
def fromstatus(cls, status):
@@ -44,9 +45,9 @@ class Action(enum.Enum):
Status.ACTIVE: cls.ACTIVE,
Status.FINAL: cls.FINAL,
Status.RETRACTED: cls.RETRACT,
- Status.OBSOLETED: cls.OBSOLETE,
+ Status.OBSOLETE: cls.OBSOLETE,
Status.DEPRECATED: cls.DEPRECATE,
- Status.DEFERRED: cls.DEFERRED,
+ Status.DEFERRED: cls.DEFER,
}[status]
diff --git a/xep-0001.xml b/xep-0001.xml
index 4b83834..8679a33 100644
--- a/xep-0001.xml
+++ b/xep-0001.xml
@@ -219,7 +219,7 @@
</section1>
<section1 topic='XEP Types' anchor='types'>
<p>The five XEP types are described in the following sections.</p>
- <p>The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs in the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
+ <p>The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs is the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
<p>This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.</p>
<section2 topic='Standards Track' anchor='types-Standards-Track'>
<p>A <span class='ref'>Standards Track XEP</span> defines one of the following:</p>
@@ -406,7 +406,7 @@ Experimental ----> Proposed ----> Active
<p>Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track XEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol and deployment of such implementations. XEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the XMPP Extensions Editor and/or XMPP Council regarding this important task.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
- <p>Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approbved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.</p>
+ <p>Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in &xep0030;).</p>
diff --git a/xep-0045.xml b/xep-0045.xml
index 238d2fc..86a4f1f 100644
--- a/xep-0045.xml
+++ b/xep-0045.xml
@@ -46,6 +46,14 @@
<registry/>
&stpeter;
<revision>
+ <version>1.29</version>
+ <date>2017-09-01</date>
+ <initials>gl</initials>
+ <remark>
+ <p>Clarify wording for a client re-syncing to a MUC</p>
+ </remark>
+ </revision>
+ <revision>
<version>1.28</version>
<date>2017-05-31</date>
<initials>gl</initials>
@@ -1393,6 +1401,7 @@
</presence>
]]></example>
<p>Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
+ <p>When a MUC service receives an &lt;x/&gt; tagged join stanza from an already-joined client (as identified by the client's full JID), the service should assume that the client lost its synchronization, and therefore it SHOULD send exactly the same stanzas to the client as if it actually just joined the MUC. The server MAY also send a presence update to the other participants according to the received join presence.</p>
</section3>
<section3 topic='Presence Broadcast' anchor='enter-pres'>
diff --git a/xep-0065.xml b/xep-0065.xml
index da8162d..0bf7a29 100644
--- a/xep-0065.xml
+++ b/xep-0065.xml
@@ -315,18 +315,6 @@
]]></example>
<p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p>
<example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[
-<iq from='streamer.example.com'
- id='uj2c15z9'
- to='requester@example.com/foo'
- type='error'>
- <error type='auth'>
- <forbidden
- xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
- </error>
-</iq>
-]]></example>
- <p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p>
- <example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[
<iq from='requester@example.com/foo'
id='uj2c15z9'
to='streamer.example.com'
diff --git a/xep-0234.xml b/xep-0234.xml
index 301acea..5db892d 100644
--- a/xep-0234.xml
+++ b/xep-0234.xml
@@ -399,7 +399,7 @@
<td>OPTIONAL</td>
</tr>
</table>
- <p>One or more &lt;hash/&gt; elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. If there is no computed hash value, the &lt;hash/&gt; element(s) MUST possess an 'algo' attribute specifying which hash algorithm will be used. Once a hash has been calculated by the File Sender, the File Sender SHOULD inform the File Receiver of the hash value as described in <link url='#checksum'>Checksum</link>.</p>
+ <p>One or more &lt;hash/&gt; elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. If there is no computed hash value, the &lt;hash/&gt; element(s) MUST possess an 'algo' attribute specifying which hash algorithm will be used. Once a hash has been calculated by the File Sender, the File Sender SHOULD inform the File Receiver of the hash value as described in <link url='#hash'>Checksum</link>.</p>
<p>Additional elements MAY be included as children of the &lt;file/&gt; element to provide additional metadata about the file, such as &xep0264;.</p>
<p>The optional &lt;range/&gt; element MAY possess two attributes:</p>
<table caption='Range Element Attributes'>
diff --git a/xep-0278.xml b/xep-0278.xml
index f6e9255..1a678e2 100644
--- a/xep-0278.xml
+++ b/xep-0278.xml
@@ -3,6 +3,8 @@
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY CHANNEL "&lt;channel/&gt;">
<!ENTITY RELAY "&lt;relay/&gt;">
+ <!ENTITY STUN "&lt;stun/&gt;">
+ <!ENTITY TURN "&lt;turn/&gt;">
<!ENTITY SERVICES "&lt;services/&gt;">
<!ENTITY TRACKER "&lt;tracker/&gt;">
%ents;
@@ -14,7 +16,7 @@
<abstract>This documents specifies how Jingle Clients can interact with Jingle Relay Nodes Services and how XMPP entities can provide, search and list available Jingle Relay Nodes.</abstract>
&LEGALNOTICE;
<number>0278</number>
- <status>Deferred</status>
+ <status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -34,6 +36,12 @@
</author>
<revision>
<version>0.2</version>
+ <date>2017-09-14</date>
+ <initials>tc</initials>
+ <remark><p>Added TURN Credentials Service Support.</p></remark>
+ </revision>
+ <revision>
+ <version>0.2</version>
<date>2011-06-21</date>
<initials>tc</initials>
<remark><p>Added STUN Service Tracking Support. Removed Public IP requirement for Relay Service.</p></remark>
@@ -115,6 +123,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<services xmlns='http://jabber.org/protocol/jinglenodes'>
<relay policy='public' address='montague.lit' protocol='udp'/>
<tracker policy='public' address='capulet.lit' protocol='udp'/>
+ <turn policy='public' address='stun.capulet.lit' protocol='udp'/>
<stun policy='public' address='200.111.111.111' port='3857' protocol='udp'/>
</services>
</iq>
@@ -194,6 +203,34 @@ All signalling, request, response and publishing is done via XMPP, not requiring
]]></example>
<p><em>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</em></p>
</section2>
+ <section2 topic="Jingle Client Consuming TURN Credentials Service" anchor="clientconsumingturncredentials">
+ <p>A Jingle Client can request volative TURN credentials, to be used in cases where connectivity check is a requirement. Like, for example, WebRTC. The concept and mechanism is quite similar to the RFC draft <link url='https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00'>REST API For Access To TURN Services'.</link></p>
+ <p>TURN provides an access control mechanism described in &rfc5389;, where long-term credentials are provided as part of the TURN protocol. Therefore the credentials provided in this Jingle Nodes mechanism are time-limited, but SHOULD be used as long-term credentials, when authentication against a TURN Server.
+ </p>
+ <p>
+ <em>Note: There is no need to run TURN server or support within a Jingle Relay. This mechanism allows decoupled deployment of distributed TURN Servers, without the requirement of database based authentication. </em>
+ </p>
+ <example caption="TURN Credentials request"><![CDATA[
+<iq from='romeo@montague.lit/orchard'
+ id='uw72g176'
+ to='juliet@capulet.lit/balcony'
+ type='get'>
+ <turn xmlns='http://jabber.org/protocol/jinglenodes#turncredentials' protocol='udp'/>
+</iq>
+]]></example>
+ <example caption="TUNR Credentials Returned by the service"><![CDATA[
+<iq from='juliet@capulet.lit/balcony'
+ id='uw72g176'
+ to='romeo@montague.lit/orchard'
+ type='result'>
+ <turn ttl='60000'
+ uri='turn:200.20.2.10:1984?transport=udp'
+ username='1433895918506:romeocapulet'
+ password='1Dj9XZ5fwvKS6YoQZOoORcFnXaI='
+ />
+</iq>
+]]></example>
+ </section2>
</section1>
<section1 topic="Services Definitions" anchor="servicesdefinition">
<section2 topic="Relay Channel Service" anchor="relaychannelservice">
@@ -293,7 +330,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</section3>
</section2>
<section2 topic="Services Element" anchor="def-services">
- <p>The &SERVICES; element MAY be empty or contain &RELAY; and/or &TRACKER; elements.</p>
+ <p>The &SERVICES; element MAY be empty or contain &RELAY;, &STUN; and/or &TRACKER; elements.</p>
<p>The attributes of the &RELAY; and &TRACKER; element are as follows.</p>
<table caption="Attributes of Relay and Tracker Elements">
<tr>
@@ -323,6 +360,48 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</tr>
</table>
</section2>
+<section2 topic="TURN Credentials Service Element" anchor="def-turn-credentials">
+ <p>The attributes of the &TURN; element are as follows.</p>
+ <table caption="Attributes of TURN Elements">
+ <tr>
+ <th>Attribute</th>
+ <th>Definition</th>
+ <th>Inclusion</th>
+ </tr>
+ <tr>
+ <td>ttl</td>
+ <td>The duration in seconds for which the provided credentials are valid.</td>
+ <td>REQUIRED</td>
+ </tr>
+ <tr>
+ <td>uri</td>
+ <td>The TURN Server URI.</td>
+ <td>REQUIRED</td>
+ </tr>
+ <tr>
+ <td>username</td>
+ <td>The username to be used on TURN authentication. THe recommended format is a colon-delimited concatenation of expiration timestamp and the requester bare JID.</td>
+ <td>REQUIRED</td>
+ </tr>
+ <tr>
+ <td>password</td>
+ <td>The ppassword to be used on TURN authentication. Is the result of 'base64(hmac(secret_key, username))'. Where 'secret_key' is shared between the TURN server and entity providing the credentials.</td>
+ <td>REQUIRED</td>
+ </tr>
+ </table>
+ <section3 topic="Ttl Attribute" anchor="def-ttlattribute">
+ <p>The duration in seconds for which the provided credentials are valid. The usual and recommended value is 86400 seconds (one day).</p>
+ </section3>
+ <section3 topic="URI Attribute" anchor="def-uriattribute">
+ <p>The TURN Server URI as described in <link url="https://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris-03">I-D.petithuguenin-behave-turn-uris</link></p>
+ </section3>
+ <section3 topic="Username Attribute" anchor="def-ttlattribute">
+ <p>WebRTC's TURN request uses the 'username' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash.</p>
+ </section3>
+ <section3 topic="Password Attribute" anchor="def-ttlattribute">
+ <p>Along with 'username', WebRTC's TURN request uses the 'password' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash.</p>
+ </section3>
+</section2>
</section1>
<section1 topic="Determining Support" anchor="support">
<p>To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.</p>
@@ -342,8 +421,9 @@ All signalling, request, response and publishing is done via XMPP, not requiring
to='romeo@montague.lit/orchard'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
- <feature var='http://jabber.org/protocol/jinglenodes'/>
- <feature var='http://jabber.org/protocol/jinglenodes#channel'/>
+ <feature var='http://jabber.org/protocol/jinglenodes'/>
+ <feature var='http://jabber.org/protocol/jinglenodes#channel'/>
+ <feature var='http://jabber.org/protocol/jinglenodes#turncredentials'/>
</query>
</iq>
]]></example>
@@ -356,6 +436,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<em>Note: This use case is also similar to a Jingle to SIP Interoperability Service.</em>
</p>
</section2>
+ <section2 topic="Jingle Client that uses WebRTC with TURN required" anchor="webrtcturn">
+ <p>A Jingle Client that uses WebRTC, therefore requiring a TURN Server and its credentials to successfully alocate channels. This specification describes a simple way of discovering TURN Services and retrieving credentials to successfully allocate channels.
+ This also simplifies deployment and distribution of TURN servers, since its stateless authentication does not require connectivity to database authoriztion services.</p>
+ </section2>
<section2 topic="Jingle Client with ICE-UDP Transport with STUN support but no TURN support" anchor="iceudpnoturn">
<p>A Jingle Client with STUN support but no TURN support can use Relay Node Services as the fallback candidate instead of a TURN candidate. For instance, after a connectivity check proccess, none of the direct candidates worked. The Client can use the Relay Node Candidate as the fallback candidate(the lowest priority candidate).</p>
</section2>
@@ -420,6 +504,13 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:attribute name='expire' type='xs:string' use='required'/>
</xs:element>
+ <xs:element name='turn'>
+ <xs:attribute name='ttl' type='xs:string' use='required'/>
+ <xs:attribute name='uri' type='xs:string' use='required'/>
+ <xs:attribute name='username' type='xs:string' use='required'/>
+ <xs:attribute name='password' type='xs:string' use='required'/>
+ </xs:element>
+
<xs:element name='services'>
<xs:complexType>
<xs:sequence>
@@ -435,6 +526,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
+ <xs:element name='turn'
+ type='serviceElementType'
+ minOccurs='0'
+ maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
diff --git a/xep-0319.xml b/xep-0319.xml
index 26a5712..870fc54 100644
--- a/xep-0319.xml
+++ b/xep-0319.xml
@@ -25,6 +25,18 @@
<shortname>idle</shortname>
&tobias;
<revision>
+ <version>1.0.2</version>
+ <date>2017-07-17</date>
+ <initials>egp</initials>
+ <remark><p>Make the schema more precise about a date being a xs:dateTime.</p></remark>
+ </revision>
+ <revision>
+ <version>1.0.1</version>
+ <date>2017-05-30</date>
+ <initials>egp</initials>
+ <remark><p>Be precise about the &xep0082; profile used.</p></remark>
+ </revision>
+ <revision>
<version>1.0</version>
<date>2015-04-02</date>
<initials>XEP editor (mam)</initials>
@@ -51,7 +63,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This protocol describes a way to communicate a user's last interaction time with other XMPP entities over &PRESENCE; stanzas. For the purposes of this document, user interaction here refers to a human end user interacting with her device by means of a keyboard, mouse, touch screen, and so on. Based on this information XMPP clients can display the time a contact went idle or a duration for how long a contact has been idle, thereby allowing end users to estimate the expected responsiveness of their contacts.</p>
- <p>This protocol uses absolute timestamps formatted according to &xep0082;, indicated as value of the 'since' attribute in the &lt;idle/&gt; element.</p>
+ <p>This protocol uses absolute timestamps formatted according to the DateTime profile of &xep0082;, indicated as value of the 'since' attribute in the &lt;idle/&gt; element.</p>
<p>Experience has shown a number of issues with &xep0256;:</p>
<ul>
<li>The use of relative durations is too vague. It requires additional information from &xep0203; to provide a reliable user experience.</li>
@@ -98,7 +110,7 @@
<xs:element name="idle">
<xs:complexType>
- <xs:attribute name="since" use="required" type="xs:string"/>
+ <xs:attribute name="since" use="required" type="xs:dateTime"/>
</xs:complexType>
</xs:element>
diff --git a/xep-0327.xml b/xep-0327.xml
index 8ac2f6b..4404be6 100644
--- a/xep-0327.xml
+++ b/xep-0327.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension for the third-party control of telephone calls and other similar media sessions. The protocol includes support for session management/signaling, as well as advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. The protocol serves a different purpose from that of first-party protocols such as Jingle or SIP, and is compatible with those protocols.</abstract>
&LEGALNOTICE;
<number>0327</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -35,6 +35,12 @@
<uri>http://tropo.com</uri>
</author>
<revision>
+ <version>0.8</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.7</version>
<date>2015-07-15</date>
<initials>bl</initials>
diff --git a/xep-0329.xml b/xep-0329.xml
index becbefe..a97bdf3 100644
--- a/xep-0329.xml
+++ b/xep-0329.xml
@@ -10,7 +10,7 @@
<abstract>This document specifies a simple extension to existing protocols that allows an entity to request information about files.</abstract>
&LEGALNOTICE;
<number>0329</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -33,6 +33,12 @@
</author>
&lance;
<revision>
+ <version>0.4</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.3</version>
<date>2016-08-07</date>
<initials>egp</initials>
diff --git a/xep-0332.xml b/xep-0332.xml
index 19ea0d4..b127383 100644
--- a/xep-0332.xml
+++ b/xep-0332.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.</abstract>
&LEGALNOTICE;
<number>0332</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<lastcall>2014-10-21</lastcall>
<type>Standards Track</type>
<sig>Standards</sig>
@@ -28,6 +28,12 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&peterwaher;
+ <revision>
+ <version>0.5</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.4</version>
<date>2015-11-09</date>
diff --git a/xep-0333.xml b/xep-0333.xml
index ed53d7c..31c31db 100644
--- a/xep-0333.xml
+++ b/xep-0333.xml
@@ -10,7 +10,7 @@
<abstract>This specification describes a solution of marking the last received, displayed and acknowledged message in a chat.</abstract>
&LEGALNOTICE;
<number>0333</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<lastcall>2017-03-01</lastcall>
<lastcall>2017-02-22</lastcall>
<lastcall>2017-02-11</lastcall>
@@ -31,6 +31,12 @@
<jid>im@spencermacdonald.com</jid>
</author>
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2.1</version>
<date>2015-10-28</date>
<initials>XEP Editor (mam)</initials>
diff --git a/xep-0337.xml b/xep-0337.xml
index d74d5dc..d24b315 100644
--- a/xep-0337.xml
+++ b/xep-0337.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
&LEGALNOTICE;
<number>0337</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -22,6 +22,12 @@
<supersededby/>
<shortname>eventlogging</shortname>
&peterwaher;
+ <revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.2</version>
<date>2015-11-09</date>
diff --git a/xep-0338.xml b/xep-0338.xml
index f9ede67..36e2e5d 100644
--- a/xep-0338.xml
+++ b/xep-0338.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle</abstract>
&LEGALNOTICE;
<number>0338</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -22,6 +22,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&fippo;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2014-01-08</date>
<initials>psa</initials>
diff --git a/xep-0339.xml b/xep-0339.xml
index a473fb5..e1aca96 100644
--- a/xep-0339.xml
+++ b/xep-0339.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle</abstract>
&LEGALNOTICE;
<number>0339</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -22,6 +22,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&fippo;
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2</version>
<date>2015-11-09</date>
<initials>ph</initials>
diff --git a/xep-0340.xml b/xep-0340.xml
index db853c8..b8ffb84 100644
--- a/xep-0340.xml
+++ b/xep-0340.xml
@@ -14,7 +14,7 @@
</abstract>
&LEGALNOTICE;
<number>0340</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -40,6 +40,12 @@
<jid>lubo@sip-communicator.org</jid>
</author>
&fippo;
+ <revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.1</version>
<date>2014-01-08</date>
diff --git a/xep-0341.xml b/xep-0341.xml
index e57326e..051ffcf 100644
--- a/xep-0341.xml
+++ b/xep-0341.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for performing Call Progress Analysis on a call under the control of a Rayo client.</abstract>
&LEGALNOTICE;
<number>0341</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -29,6 +29,12 @@
<uri>http://langfeld.me</uri>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2014-01-14</date>
<initials>psa</initials>
diff --git a/xep-0342.xml b/xep-0342.xml
index 1c722a7..421dd36 100644
--- a/xep-0342.xml
+++ b/xep-0342.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for sending and receiving faxcimilies via a call under the control of a Rayo client.</abstract>
&LEGALNOTICE;
<number>0342</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -30,6 +30,12 @@
<uri>http://langfeld.me</uri>
</author>
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2</version>
<date>2014-03-13</date>
<initials>bl</initials>
diff --git a/xep-0343.xml b/xep-0343.xml
index 20516ae..0538564 100644
--- a/xep-0343.xml
+++ b/xep-0343.xml
@@ -15,7 +15,7 @@
<abstract>This specification defines how to use the ICE-UDP Jingle transport method to send media data using WebRTC DataChannels, so technically uses DTLS/SCTP on top of the Interactive Connectivity Establishment (ICE) methodology, which provides robust NAT traversal for media traffic.</abstract>
&LEGALNOTICE;
<number>0343</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -32,6 +32,12 @@
<email>bavendiek@dbis.rwth-aachen.de</email>
</author>
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2</version>
<date>2014-07-15</date>
<initials>ph</initials>
diff --git a/xep-0344.xml b/xep-0344.xml
index 69b9e79..54e264d 100644
--- a/xep-0344.xml
+++ b/xep-0344.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides documentation how Server Dialback is used together with Transport Layer Security, and discusses how the security considerations of Dialback are changed by the introduction of TLS and/or DNSSEC.</abstract>
&LEGALNOTICE;
<number>0344</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -24,6 +24,12 @@
&fippo;
&dcridland;
<revision>
+ <version>0.4</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.3</version>
<date>2015-03-23</date>
<initials>dwd/ph</initials>
diff --git a/xep-0345.xml b/xep-0345.xml
index 6bbf40e..9f13217 100644
--- a/xep-0345.xml
+++ b/xep-0345.xml
@@ -13,7 +13,7 @@
</abstract>
&LEGALNOTICE;
<number>0345</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Procedural</type>
<sig>None</sig>
<approver>Board</approver>
@@ -22,6 +22,12 @@
<supersededby/>
<shortname>N/A</shortname>
&dcridland;
+ <revision>
+ <version>0.4</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.3</version>
<date>2014-08-04</date>
diff --git a/xep-0346.xml b/xep-0346.xml
index 93ec322..c48c75a 100644
--- a/xep-0346.xml
+++ b/xep-0346.xml
@@ -12,7 +12,7 @@
<abstract>This specification describes a series of conventions that allow the management of form templates and publishing of completed forms.</abstract>
&LEGALNOTICE;
<number>0346</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -27,6 +27,12 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&ksmithisode;
+ <revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.1</version>
<date>2014-04-10</date>
diff --git a/xep-0347.xml b/xep-0347.xml
index d6b9ada..0f30dbb 100644
--- a/xep-0347.xml
+++ b/xep-0347.xml
@@ -14,7 +14,7 @@
<abstract>This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things.</abstract>
&LEGALNOTICE;
<number>0347</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -41,6 +41,12 @@
<jid>TBD</jid>
<uri>http://www-rnks.informatik.tu-cottbus.de/~rklauck</uri>
</author>
+ <revision>
+ <version>0.5</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.4.1</version>
<date>2016-08-20</date>
diff --git a/xep-0348.xml b/xep-0348.xml
index aeaab22..fbc5a8b 100644
--- a/xep-0348.xml
+++ b/xep-0348.xml
@@ -10,7 +10,7 @@
<abstract>This specification describes a method whereby a client can sign a form using credentials not related to the current connection.</abstract>
&LEGALNOTICE;
<number>0348</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -25,6 +25,12 @@
<supersededby/>
<shortname>signing-forms</shortname>
&peterwaher;
+ <revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.2</version>
<date>2015-11-09</date>
diff --git a/xep-0349.xml b/xep-0349.xml
index 21005e4..20ba9d2 100644
--- a/xep-0349.xml
+++ b/xep-0349.xml
@@ -10,7 +10,7 @@
<abstract>This specification describes an extension to the Rayo protocol to support clustering of Rayo servers and their presentation as a unified service.</abstract>
&LEGALNOTICE;
<number>0349</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -35,6 +35,12 @@
<uri>http://tropo.com</uri>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2014-06-18</date>
<initials>editorc(mam)</initials>
diff --git a/xep-0350.xml b/xep-0350.xml
index 673893e..f2826c2 100644
--- a/xep-0350.xml
+++ b/xep-0350.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension for including geolocation data in XEP-0004 data forms.</abstract>
&LEGALNOTICE;
<number>0350</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@@ -31,6 +31,12 @@
<email>laukner@gmail.com</email>
<jid>laukner@jabber.org</jid>
</author>
+ <revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.1</version>
<date>2014-07-03</date>
diff --git a/xep-0351.xml b/xep-0351.xml
index ad78c23..3eddf9c 100644
--- a/xep-0351.xml
+++ b/xep-0351.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines a modern efficient way to deliver PubSub notifications.</abstract>
&LEGALNOTICE;
<number>0351</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -30,6 +30,12 @@
<jid>Binary@JRuDevels.org</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2014-08-28</date>
<initials>XEP Editor(aw)</initials>
diff --git a/xep-0353.xml b/xep-0353.xml
index 69a283f..43f2ba4 100644
--- a/xep-0353.xml
+++ b/xep-0353.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource.</abstract>
&LEGALNOTICE;
<number>0353</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -23,6 +23,12 @@
&fippo;
&stpeter;
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2.0</version>
<date>2014-10-02</date>
<initials>xd, XEP Editor: ssw</initials>
diff --git a/xep-0354.xml b/xep-0354.xml
index 48afbce..6e48a73 100644
--- a/xep-0354.xml
+++ b/xep-0354.xml
@@ -10,7 +10,7 @@
<abstract>This specification specifies customizable behavior of RFC 6121 section 8.5.2.1.1 to allow various message routing algorithms (e.g., for load balancing).</abstract>
&LEGALNOTICE;
<number>0354</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -24,6 +24,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&flow;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2014-10-15</date>
<initials>XEP Editor (aw)</initials>
diff --git a/xep-0355.xml b/xep-0355.xml
index 4877fb7..1b681f9 100644
--- a/xep-0355.xml
+++ b/xep-0355.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides a way for XMPP server to delegate treatments for a namespace to an other entity</abstract>
&LEGALNOTICE;
<number>0355</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -28,6 +28,12 @@
<email>goffi@goffi.org</email>
<jid>goffi@jabber.fr</jid>
</author>
+ <revision>
+ <version>0.4</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.3</version>
diff --git a/xep-0356.xml b/xep-0356.xml
index 4f7458f..6c54ac0 100644
--- a/xep-0356.xml
+++ b/xep-0356.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides a way for XMPP entities to have a privileged access to some other entities data</abstract>
&LEGALNOTICE;
<number>0356</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -27,6 +27,12 @@
<jid>goffi@jabber.fr</jid>
</author>
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2</version>
<date>2015-03-23</date>
<initials>jp</initials>
diff --git a/xep-0358.xml b/xep-0358.xml
index 2133def..bc40bfe 100644
--- a/xep-0358.xml
+++ b/xep-0358.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Jingle session request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the Jingle File Transfer protocol defined in XEP-0234.</abstract>
&LEGALNOTICE;
<number>0358</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@@ -25,6 +25,12 @@
&lance;
&stpeter;
<revision>
+ <version>0.4</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.3</version>
<date>2016-05-24</date>
<initials>fs</initials>
diff --git a/xep-0360.xml b/xep-0360.xml
index bc8f215..aca7908 100644
--- a/xep-0360.xml
+++ b/xep-0360.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines the term "Nonza", describing every top level stream element that is not a Stanza.</abstract>
&LEGALNOTICE;
<number>0360</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -22,6 +22,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&flow;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2015-07-14</date>
<initials>XEP Editor (mam)</initials>
diff --git a/xep-0361.xml b/xep-0361.xml
index 406c4c8..cd4bdac 100644
--- a/xep-0361.xml
+++ b/xep-0361.xml
@@ -14,7 +14,7 @@
</abstract>
&LEGALNOTICE;
<number>0361</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -32,6 +32,12 @@
<jid>steve.kille@isode.com</jid>
</author>
<revision>
+ <version>0.3</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.2</version>
<date>2015-07-18</date>
<initials>sek</initials>
diff --git a/xep-0362.xml b/xep-0362.xml
index fec30bc..1325ec4 100644
--- a/xep-0362.xml
+++ b/xep-0362.xml
@@ -10,7 +10,7 @@
<abstract>This specification provides a means for transporting messages from the Raft consensus algorithm over XMPP.</abstract>
&LEGALNOTICE;
<number>0362</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -29,6 +29,12 @@
<jid>peter@membrey.hk</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2015-08-11</date>
<initials>XEP Editor (mam)</initials>
diff --git a/xep-0365.xml b/xep-0365.xml
index cbc8f88..096cfb7 100644
--- a/xep-0365.xml
+++ b/xep-0365.xml
@@ -13,7 +13,7 @@
</abstract>
&LEGALNOTICE;
<number>0365</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -31,6 +31,12 @@
<jid>steve.kille@isode.com</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2015-09-17</date>
<initials>XEP Editor (mam)</initials>
diff --git a/xep-0367.xml b/xep-0367.xml
index 70031ac..21d8256 100644
--- a/xep-0367.xml
+++ b/xep-0367.xml
@@ -14,7 +14,7 @@
</abstract>
&LEGALNOTICE;
<number>0367</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -31,6 +31,12 @@
<email>cpetchell@atlassian.com</email>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2015-12-15</date>
<initials>XEP Editor (asw)</initials>
diff --git a/xep-0370.xml b/xep-0370.xml
index f61054b..e95d55d 100644
--- a/xep-0370.xml
+++ b/xep-0370.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines two Jingle transport methods for establishing HTTP connections for either uploading or downloading data.</abstract>
&LEGALNOTICE;
<number>0370</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -22,6 +22,12 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&lance;
+ <revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.1</version>
<date>2016-01-12</date>
diff --git a/xep-0371.xml b/xep-0371.xml
index 32cd2f1..c0ed18d 100644
--- a/xep-0371.xml
+++ b/xep-0371.xml
@@ -10,7 +10,7 @@
<abstract>This specification defines a Jingle transport method that results in sending media data using datagram associations via the User Datagram Protocol (UDP) or using end-to-end connections via the Transport Control Protocol (TCP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology (which provides robust NAT traversal for media traffic) and also supports the ability to exchange candidates throughout the life of the session, consistent with so-called "Trickle ICE" (draft-ietf-ice-trickle).</abstract>
&LEGALNOTICE;
<number>0371</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -28,6 +28,12 @@
<shortname>jingle-ice</shortname>
&stpeter;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2016-01-21</date>
<initials>XEP Editor (asw)</initials>
diff --git a/xep-0372.xml b/xep-0372.xml
index 9339e50..28d9746 100644
--- a/xep-0372.xml
+++ b/xep-0372.xml
@@ -11,7 +11,7 @@
<abstract>This document defines a method for one XMPP stanza to provide references to another entity, such as mentioning users, HTTP resources, or other XMPP resources.</abstract>
&LEGALNOTICE;
<number>0372</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -26,6 +26,12 @@
<shortname>Refs</shortname>
&ksmithisode;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2016-03-22</date>
<initials>XEP Editor (asw)</initials>
diff --git a/xep-0373.xml b/xep-0373.xml
index 968d074..8fd12c2 100644
--- a/xep-0373.xml
+++ b/xep-0373.xml
@@ -18,7 +18,7 @@
devices.</abstract>
&LEGALNOTICE;
<number>0373</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -47,6 +47,12 @@
<jid>valodim@stratum0.org</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1.3</version>
<date>2016-07-15</date>
<initials>fs (XEP Editor: ssw)</initials>
diff --git a/xep-0376.xml b/xep-0376.xml
index b1c0581..212ff5e 100644
--- a/xep-0376.xml
+++ b/xep-0376.xml
@@ -10,7 +10,7 @@
<abstract>This specification describes a new model for handling remote pubsub services and a protocol for doing so.</abstract>
&LEGALNOTICE;
<number>0376</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -28,6 +28,12 @@
<jid>dave.cridland@surevine.com</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1.1</version>
<date>2016-07-20</date>
<initials>dwd</initials>
diff --git a/xep-0377.xml b/xep-0377.xml
index ed3b638..69c1849 100644
--- a/xep-0377.xml
+++ b/xep-0377.xml
@@ -13,7 +13,7 @@
</abstract>
&LEGALNOTICE;
<number>0377</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -27,6 +27,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&sam;
<revision>
+ <version>0.2</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
+ <revision>
<version>0.1.0</version>
<date>2016-05-25</date>
<initials>ssw</initials>
diff --git a/xep-0378.xml b/xep-0378.xml
index f4dfb3a..1dd9338 100644
--- a/xep-0378.xml
+++ b/xep-0378.xml
@@ -15,7 +15,7 @@
</abstract>
&LEGALNOTICE;
<number>0378</number>
- <status>Experimental</status>
+ <status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@@ -27,6 +27,12 @@
<supersededby/>
<shortname>OTR-DISCO</shortname>
&sam;
+ <revision>
+ <version>0.1</version>
+ <date>2017-09-11</date>
+ <initials>XEP Editor (jwi)</initials>
+ <remark>Defer due to lack of activity.</remark>
+ </revision>
<revision>
<version>0.0.1</version>
<date>2016-07-15</date>
diff --git a/xep-0384.xml b/xep-0384.xml
index 29d76c9..a06ee04 100644
--- a/xep-0384.xml
+++ b/xep-0384.xml
@@ -28,6 +28,15 @@
<jid>andy@strb.org</jid>
</author>
<revision>
+ <version>0.2</version>
+ <date>2017-06-02</date>
+ <initials>dg</initials>
+ <remark>
+ <p>Depend on SignalProtocol instead of Olm.</p>
+ <p>Changed to eu.siacs.conversations.axolotl Namespace which is currently used in the wild</p>
+ </remark>
+ </revision>
+ <revision>
<version>0.1</version>
<date>2016-12-07</date>
<initials>XEP Editor: ssw</initials>
@@ -63,17 +72,21 @@
external complexity.
</p>
<p>
- This XEP defines a protocol that leverages &olm; encryption to provide
+ This XEP defines a protocol that leverages the SignalProtocol encryption to provide
multi-end to multi-end encryption, allowing messages to be synchronized
- securely across multiple clients, even if some of them are offline. Olm
+ securely across multiple clients, even if some of them are offline. The SignalProtocol
is a cryptographic double ratched protocol based on work by Trevor Perrin
- and Moxie Marlinspike first published as the Axolotl protocol.
+ and Moxie Marlinspike first published as the Axolotl protocol. While the
+ protocol itself has specifications in the public domain, the
+ protobuf-based wire format of the signal protocol is not fully
+ documented. The signal protocol currently only exists in GPLv3-licensed
+ implementations maintained by OpenWhisperSystems.
</p>
</section2>
<section2 topic='Overview' anchor='intro-overview'>
<p>
The general idea behind this protocol is to maintain separate,
- long-standing Olm-encrypted sessions with each device of each contact
+ long-standing SignalProtocol-encrypted sessions with each device of each contact
(as well as with each of our other devices), which are used as secure key
transport channels. In this scheme, each message is encrypted with a
fresh, randomly generated encryption key. An encrypted header is added to
@@ -87,14 +100,14 @@
</p>
<p>
As the encrypted payload is common to all recipients, it only has to be
- included once, reducing overhead. Furthermore, Olm's transparent handling
+ included once, reducing overhead. Furthermore, SignalProtocols’s transparent handling
of messages that were lost or received out of order, as well as those sent
while the recipient was offline, is maintained by this protocol. As a
result, in combination with &xep0280; and &xep0313;, the desired property
of inter-client history synchronization is achieved.
</p>
<p>
- OMEMO currently uses version 1 Olm protocol. Instead of an Axolotl key
+ OMEMO currently uses version 3 SignalProtocol. Instead of a Signal key
server, &xep0163; (PEP) is used to publish key data.
</p>
</section2>
@@ -111,7 +124,7 @@
<section2 topic='General Terms' anchor='glossary-general'>
<dl>
<di><dt>Device</dt><dd>A communication end point, i.e. a specific client instance</dd></di>
- <di><dt>OMEMO element</dt><dd>An &lt;encrypted&gt; element in the urn:xmpp:omemo:0 namespace. Can be either MessageElement or a KeyTransportElement</dd></di>
+ <di><dt>OMEMO element</dt><dd>An &lt;encrypted&gt; element in the eu.siacs.conversations.axolotl namespace. Can be either MessageElement or a KeyTransportElement</dd></di>
<di><dt>MessageElement</dt><dd>An OMEMO element that contains a chat message. Its &lt;payload&gt;, when decrypted, corresponds to a &lt;message&gt;'s &lt;body&gt;.</dd></di>
<di><dt>KeyTransportElement</dt><dd>An OMEMO element that does not have a &lt;payload&gt;. It contains a fresh encryption key, which can be used for purposes external to this XEP.</dd></di>
<di><dt>Bundle</dt><dd>A collection of publicly accessible data that can be used to build a session with a device, namely its public IdentityKey, a signed PreKey with corresponding signature, and a list of (single use) PreKeys.</dd></di>
@@ -120,12 +133,12 @@
</dl>
</section2>
- <section2 topic='Olm-specific' anchor='glossary-olm'>
+ <section2 topic='SignalProtocol-specific' anchor='glossary-signalprotocol'>
<dl>
<di><dt>IdentityKey</dt><dd>Per-device public/private key pair used to authenticate communications</dd></di>
<di><dt>PreKey</dt><dd>A Diffie-Hellman public key, published in bulk and ahead of time</dd></di>
- <di><dt>PreKeyOlmMessage</dt><dd>An encrypted message that includes the initial key exchange. This is used to transparently build sessions with the first exchanged message.</dd></di>
- <di><dt>OlmMessage</dt><dd>An encrypted message</dd></di>
+ <di><dt>PreKeySignalMessage</dt><dd>An encrypted message that includes the initial key exchange. This is used to transparently build sessions with the first exchanged message.</dd></di>
+ <di><dt>SignalMessage</dt><dd>An encrypted message</dd></di>
</dl>
</section2>
</section1>
@@ -139,16 +152,16 @@
</p>
</section2>
<section2 topic='Discovering peer support' anchor='usecases-discovering'>
- <p>In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'urn:xmpp:omemo:0:devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist.</p>
+ <p>In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'eu.siacs.conversations.axolotl.devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist.</p>
<example caption='Devicelist update received by subscribed clients'><![CDATA[
<message from='juliet@capulet.lit'
to='romeo@montague.lit'
type='headline'
id='update_01'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
- <items node='urn:xmpp:omemo:0:devicelist'>
+ <items node='eu.siacs.conversations.axolotl.devicelist'>
<item>
- <list xmlns='urn:xmpp:omemo:0'>
+ <list xmlns='eu.siacs.conversations.axolotl'>
<device id='12345' />
<device id='4223' />
</list>
@@ -162,9 +175,9 @@
<example caption='Adding the own device ID to the list'><![CDATA[
<iq from='juliet@capulet.lit' type='set' id='announce1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
- <publish node='urn:xmpp:omemo:0:devicelist'>
+ <publish node='eu.siacs.conversations.axolotl.devicelist'>
<item>
- <list xmlns='urn:xmpp:omemo:0'>
+ <list xmlns='eu.siacs.conversations.axolotl'>
<device id='12345' />
<device id='4223' />
<device id='31415' />
@@ -178,9 +191,9 @@
<example caption='Announcing bundle information'><![CDATA[
<iq from='juliet@capulet.lit' type='set' id='announce2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
- <publish node='urn:xmpp:omemo:0:bundles:31415'>
+ <publish node='eu.siacs.conversations.axolotl.bundles:31415'>
<item>
- <bundle xmlns='urn:xmpp:omemo:0'>
+ <bundle xmlns='eu.siacs.conversations.axolotl'>
<signedPreKeyPublic signedPreKeyId='1'>
BASE64ENCODED...
</signedPreKeyPublic>
@@ -216,10 +229,10 @@
to='juliet@capulet.lit'
id='fetch1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
- <items node='urn:xmpp:omemo:0:bundles:31415'/>
+ <items node='eu.siacs.conversations.axolotl.bundles:31415'/>
</pubsub>
</iq>]]></example>
- <p>A random preKeyPublic entry is selected, and used to build an Olm session.</p>
+ <p>A random preKeyPublic entry is selected, and used to build a SignalProtocol session.</p>
</section2>
<section2 topic='Sending a message' anchor='usecases-messagesend'>
<p>
@@ -230,15 +243,15 @@
128 bit) are concatenated and for each intended recipient device,
i.e. both own devices as well as devices associated with the contact, the
result of this concatenation is encrypted using the corresponding
- long-standing Olm session. Each encrypted payload key/authentication tag
+ long-standing SignalProtocol session. Each encrypted payload key/authentication tag
tuple is tagged with the recipient device's ID. The key element MUST be
- tagged with a prekey attribute set to true if a PreKeyOlmMessage is being
+ tagged with a prekey attribute set to true if a PreKeySignalMessage is being
used. This is all serialized into a MessageElement, which is transmitted
in a &lt;message&gt; as follows:
</p>
<example caption="Sending a message"><![CDATA[
<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
- <encrypted xmlns='urn:xmpp:omemo:0'>
+ <encrypted xmlns='eu.siacs.conversations.axolotl'>
<header sid='27183'>
<key rid='31415'>BASE64ENCODED...</key>
<key prekey="true" rid='12321'>BASE64ENCODED...</key>
@@ -258,14 +271,14 @@
SHOULD have at least 128 bit) are concatenated and for each intended
recipient device, i.e. both own devices as well as devices associated
with the contact, this key is encrypted using the corresponding
- long-standing Olm session. Each encrypted payload key/authentication tag
+ long-standing SignalProtocol session. Each encrypted payload key/authentication tag
tuple is tagged with the recipient device's ID. The key element MUST be
- tagged with a prekey attribute set to true if a PreKeyOlmMessage is being
+ tagged with a prekey attribute set to true if a PreKeySignalMessage is being
used This is all serialized into a KeyTransportElement, omitting the
&lt;payload&gt; as follows:
</p>
<example caption="Sending a key"><![CDATA[
-<encrypted xmlns='urn:xmpp:omemo:0'>
+<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header sid='27183'>
<key rid='31415'>BASE64ENCODED...</key>
<key prekey="true" rid='12321'>BASE64ENCODED...</key>
@@ -276,25 +289,24 @@
<p>This KeyTransportElement can then be sent over any applicable transport mechanism.</p>
</section2>
<section2 topic='Receiving a message' anchor='usecases-receiving'>
- <p>When an OMEMO element is received, the client MUST check whether there is a &lt;key&gt; element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeyOlmMessage.</p>
+ <p>When an OMEMO element is received, the client MUST check whether there is a &lt;key&gt; element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeySignalMessage.</p>
<p>If this is the case, a new session is built from this received element. The client SHOULD then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST delete the private key belonging to the PreKey after use.</p>
- <p>If the element's contents are a OlmMessage, and the client has a session with the sender's device, it tries to decrypt the OlmMessage using this session. If the decryption fails or if the element's contents are not a OlmMessage either, the OMEMO element MUST be silently discarded.</p>
+ <p>If the element's contents are a SignalMessage, and the client has a session with the sender's device, it tries to decrypt the SignalMessage using this session. If the decryption fails or if the element's contents are not a SignalMessage either, the OMEMO element MUST be silently discarded.</p>
<p>If the OMEMO element contains a &lt;payload&gt;, it is an OMEMO message element. The client tries to decrypt the base64 encoded contents using the key and the authentication tag extracted from the &lt;key&gt; element. If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the &lt;body&gt; of the received message.</p>
<p>If the OMEMO element does not contain a &lt;payload&gt;, the client has received a KeyTransportElement. The key extracted from the &lt;key&gt; element can then be used for other purposes (e.g. encrypted file transfer).</p>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>Before publishing a freshly generated Device ID for the first time, a device MUST check whether that Device ID already exists, and if so, generate a new one.</p>
- <p>Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeyOlmMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message. </p>
- <p>As there are no explicit error messages in this protocol, if a client does receive a PreKeyOlmMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a &lt;message&gt; using a PreKeyOlmMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session.</p>
- <p>If a PreKeyOlmMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeyOlmMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.</p>
+ <p>Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeySignalMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message. </p>
+ <p>As there are no explicit error messages in this protocol, if a client does receive a PreKeySignalMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a &lt;message&gt; using a PreKeySignalMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session.</p>
+ <p>If a PreKeySignalMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeySignalMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.</p>
<p>As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a &xep0334; &lt;store /&gt; hint in their OMEMO messages. Otherwise, server implementations of &xep0313; will generally not retain OMEMO messages, since they do not contain a &lt;body /&gt;</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<!-- TODO: I think this is still true? -->
<p>
- The Olm library's reference implementation (and presumably its ports to
- various other platforms) uses a trust model that doesn't work very well with
+ The SignalProtocol-library uses a trust model that doesn't work very well with
OMEMO. For this reason it may be desirable to have the library consider all
keys trusted, effectively disabling its trust management. This makes it
necessary to implement trust handling oneself.
@@ -305,7 +317,7 @@
<p>When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex string, QR code, or other unique representation, such that it can be compared by the user.</p>
<p>While it is RECOMMENDED that clients postpone private key deletion until after MAM catch-up and this standards mandates that clients MUST NOT use duplicate-PreKey sessions for sending, clients MAY delete such keys immediately for security reasons. For additional information on potential security impacts of this decision, refer to <note>Menezes, Alfred, and Berkant Ustaoglu. "On reusing ephemeral keys in Diffie-Hellman key agreement protocols." International Journal of Applied Cryptography 2, no. 2 (2010): 154-158.</note>.</p>
<p>
- In order to be able to handle out-of-order messages, the Olm stack has to
+ In order to be able to handle out-of-order messages, the SignalProtocol stack has to
cache the keys belonging to "skipped" messages that have not been seen yet.
It is up to the implementor to decide how long and how many of such keys to
keep around.
@@ -318,9 +330,8 @@
<section2 topic='Protocol Namespaces' anchor='namespaces'>
<p>This specification defines the following XMPP namespaces:</p>
<ul>
- <li>urn:xmpp:omemo:0</li>
+ <li>eu.siacs.conversations.axolotl</li>
</ul>
- <p>The &REGISTRAR; shall include the foregoing namespace in its registry at &NAMESPACES;, as goverened by &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='versioning'>
&NSVER;
@@ -330,8 +341,8 @@
<code><![CDATA[
<xml version="1.0" encoding="utf8">
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
- targetNamespace="urn:xmpp:omemo:0"
- xmlns="urn:xmpp:omemo:0">
+ targetNamespace="eu.siacs.conversations.axolotl"
+ xmlns="eu.siacs.conversations.axolotl">
<xs:element name="encrypted">
<xs:element name="header">