mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
Merge branch 'premerge' into 'main'
Premerge See merge request xsf/xeps!37
This commit is contained in:
Jonas Schäfer
commit
d263d41b6f
@ -70,6 +70,11 @@ def accept_xep(number, last_version,
|
||||
f.write(xep_text)
|
||||
f.flush()
|
||||
|
||||
subprocess.check_call(["make", "build/xeplist.xml"])
|
||||
|
||||
with open("xep.ent", "ab") as f:
|
||||
f.write(subprocess.check_output(["python3", "tools/makeent.py", str(number)]))
|
||||
|
||||
|
||||
def isodate(s):
|
||||
return datetime.strptime(s, "%Y-%m-%d")
|
||||
@ -199,7 +204,7 @@ def main():
|
||||
"git", "reset", "HEAD", ".",
|
||||
])
|
||||
subprocess.check_call([
|
||||
"git", "add", new_filename.parts[-1],
|
||||
"git", "add", new_filename.parts[-1], "xep.ent",
|
||||
])
|
||||
if args.ask:
|
||||
flags = ["-ve"]
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0443</number>
|
||||
<status>Proposed</status>
|
||||
<status>Draft</status>
|
||||
<lastcall>2020-11-03</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
@ -63,6 +63,12 @@
|
||||
<email>georg@op-co.de</email>
|
||||
<jid>georg@yax.im</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.0.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accept as Draft as per Council vote from 2020-11-11.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3.0</version>
|
||||
<date>2020-11-10</date>
|
||||
|
||||
199
xep-0445.xml
Normal file
199
xep-0445.xml
Normal file
@ -0,0 +1,199 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Pre-Authenticated In-Band Registration</title>
|
||||
<abstract>This document extends the In-Band-Registration protocol to use
|
||||
invitation tokens, e.g. for registering accounts on non-public
|
||||
servers.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0445</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0077</spec>
|
||||
<spec>XEP-0147</spec>
|
||||
<spec>XEP-0379</spec>
|
||||
<spec>XEP-0401</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>ibr-token</shortname>
|
||||
<author>
|
||||
<firstname>Georg</firstname>
|
||||
<surname>Lukas</surname>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.2.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted by vote of Council on 2020-11-04.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-10-28</date>
|
||||
<initials>gl</initials>
|
||||
<remark>First version based on XEP-0401.</remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>There are two typical mechanisms to register an account on an XMPP server:</p>
|
||||
<ul>
|
||||
<li>Out-of-band account creation, after which the account JID and password
|
||||
need to be manually entered into an XMPP client, and</li>
|
||||
<li>&xep0077; (IBR) where an account is created and fully configured right
|
||||
from the XMPP client.</li>
|
||||
</ul>
|
||||
<p>The IBR mechanism is much more convenient for users, but also opens up
|
||||
the server to abuse, e.g. due to the mass-registration of spam bot
|
||||
accounts. Captchas, while heavily impacting well-intentioned users, are
|
||||
not a reliable mechanism to prevent abuse. This specification allows to
|
||||
restrict the IBR mechanism by requiring a registration token, e.g. for
|
||||
giving users access to a private server, without exposing their password
|
||||
to the server administrator.</p>
|
||||
<p>This specification is part of a series of documents aiming at improving
|
||||
user onboarding:</p>
|
||||
<ul>
|
||||
<li>&xep0379; to automatically accept roster subscriptions based on a
|
||||
token.</li>
|
||||
<li>&xep0401; to generate tokens that can be used for authenticating IBR.</li>
|
||||
</ul>
|
||||
<p>While this specification is designed to work together with &xep0401;, it
|
||||
can be used with invitation tokens obtained by any other mechanism. XMPP
|
||||
URIs can then be used out-of-band to deliver the invitation to a new user.</p>
|
||||
<p>A client that obtains such an XMPP URI should allow the user to register
|
||||
an XMPP account with the server that generated the URI.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases'>
|
||||
<p>A client that implements this specification needs to understand the
|
||||
&xep0147; specification, to make use of the <tt>register</tt> query
|
||||
action and the <tt>preauth</tt> parameter. Three URI formats
|
||||
are defined.</p>
|
||||
<section2 topic="Registration with pre-defined account name">
|
||||
<p>An invitation to register an account can contain a specific XMPP
|
||||
address (with a pre-defined user account name) to be registered. A
|
||||
client should populate the address field in the IBR dialog with this
|
||||
address and disallow changing the address.</p>
|
||||
<code caption="Registration URI with pre-defined account name">xmpp:juliet@example.com?register;preauth=TOKEN</code>
|
||||
</section2>
|
||||
|
||||
<section2 topic="Registration on a server">
|
||||
<p>An invitation to register an account can contain just the server domain
|
||||
to register on. A client should populate the address field in the IBR
|
||||
dialog with this domain and allow entering the desired account name.</p>
|
||||
<code caption="Registration URI without account name">xmpp:example.com?register;preauth=TOKEN</code>
|
||||
</section2>
|
||||
|
||||
<section2 topic="Contact Invitation with IBR">
|
||||
<p>A contact invitation with a registration token (&xep0379;) might
|
||||
indicate that the token can also be used to register an account on that
|
||||
server (<tt>ibr=y</tt>). If the receiving client already has an account
|
||||
configured, it may skip account registration and simply add the contact
|
||||
as defined in <cite>XEP-0379</cite>. The client may also register a new
|
||||
account on the domain of the proposed contact, allowing the user to
|
||||
enter the desired account name.</p>
|
||||
<code caption="Contact URI with Pre-Authenticated IBR support">xmpp:romeo@example.com?roster;preauth=TOKEN;ibr=y</code>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Discovery' anchor='discover'>
|
||||
<p>While a registration URI is an indication that the respective server
|
||||
supports Pre-Authenticated IBR, a URI might be manipulated and is not
|
||||
guaranteed to be reliable.</p>
|
||||
<p>Therefore, when performing the account creation, the client needs to
|
||||
ensure that the server supports the Pre-Authenticated IBR protocol, as denoted by
|
||||
the <strong><register xmlns='urn:xmpp:ibr-token:0'></strong>
|
||||
stream feature:</p>
|
||||
<example caption="Stream features of a server that accepts invitations"><![CDATA[
|
||||
<stream:features>
|
||||
<mechanisms xmlns='urn:xmpp:sasl:0'>
|
||||
<mechanism>EXTERNAL</mechanism>
|
||||
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
||||
<mechanism>SCRAM-SHA-1</mechanism>
|
||||
<mechanism>PLAIN</mechanism>
|
||||
</mechanisms>
|
||||
<register xmlns='urn:xmpp:ibr-token:0'/>
|
||||
<register xmlns='http://jabber.org/features/iq-register'/>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
</section1>
|
||||
<section1 topic='Pre-Authenticated In-Band Registration' anchor='preauth-ibr'>
|
||||
<p>In order to allow invited users to register on a server, the
|
||||
registration processs as defined in &xep0077; needs to be extended. The
|
||||
invited user's client needs to connect to the server and check that the
|
||||
invitation stream feature
|
||||
(<strong><register xmlns='urn:xmpp:ibr-token:0'></strong>) is present.
|
||||
After that, the client initiates the registration flow by sending the
|
||||
preauth token to the server:</p>
|
||||
<example caption="Client initiates pre-authenticated IBR"><![CDATA[
|
||||
<iq type='set' to='example.com' id='pa1'>
|
||||
<preauth xmlns='urn:xmpp:pars:0' token='TOKEN' />
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Upon receiving the preauth request, the server must validate that the
|
||||
token is acceptable for account registration. However, single-use tokens
|
||||
MUST NOT be considered used until the actual registration has succeeded.
|
||||
</p>
|
||||
<p>In addition, if the token has an expiration time, it MUST only be
|
||||
checked at this point. Subsequent actions performed by the client during
|
||||
the current session that require a valid token MUST NOT be rejected due
|
||||
to token expiry.
|
||||
</p>
|
||||
<p>If the token is acceptable, the server responds with success, and
|
||||
indicates the client may now proceed with account registration:
|
||||
</p>
|
||||
<example caption="Server accepts invitation token"><![CDATA[
|
||||
<iq type='result' from='example.com' id='pa1' />
|
||||
]]></example>
|
||||
<p>If the token provided by the client was unknown, invalid or expired, the
|
||||
server should return an appropriate error to the client:</p>
|
||||
<example caption="Server rejects invitation token"><![CDATA[
|
||||
<iq type="error" from="example.com" id="pa1">
|
||||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<text>The provided token is invalid or expired</text>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In the success case, the client proceeds with registration as defined in
|
||||
&xep0077;. If the token is rejected by the server, the client still MAY
|
||||
attempt to perform IBR if the server allows that.</p>
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>If a username was specified when creating an invitation token, the
|
||||
server SHOULD NOT create an account on the server until the invitee
|
||||
actually registers it with the corresponding token.
|
||||
The server MUST reserve the username at least until the corresponding
|
||||
token expires.</p>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='XMPP Server Suggestion for Invitees'>
|
||||
<p>If the invitee opens an invitation URI with <strong>ibr=y</strong> and
|
||||
chooses to create a new account, the client SHOULD pre-fill the
|
||||
inviter JID's domain part as the new account's domain. The client MAY
|
||||
provide a mechanism to enter or choose a different server, though.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>See security considerations in &xep0379;.</p>
|
||||
</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 only makes use of the XMPP URI elements defined in
|
||||
&xep0401;</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
152
xep-0446.xml
Normal file
152
xep-0446.xml
Normal file
@ -0,0 +1,152 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>File metadata element</title>
|
||||
<abstract>This specification defines a generic file metadata element to be used in other specifications.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0446</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
<spec>XEP-0264</spec>
|
||||
<spec>XEP-0300</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>file-metadata</shortname>
|
||||
&larma;
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted by vote of Council on 2020-11-18.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>lmw</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
Several existing specification have the need to provide metadata on a file.
|
||||
The only specification of an element that contains file metadata so far is
|
||||
provided as part of &xep0234;. This resulted in the situation that XEPs like
|
||||
&xep0385; depend on the mostly unrelated &xep0166; just for the metadata
|
||||
element. The motiviation of this XEP is to get rid of such dependencies and
|
||||
have a dedicated place to define a file metadata element.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Element format' anchor='format'>
|
||||
<code><![CDATA[
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>text/plain</media-type>
|
||||
<name>test.txt</name>
|
||||
<date>2015-07-26T21:46:00+01:00</date>
|
||||
<size>6144</size>
|
||||
<hash xmlns='urn:xmpp:hashes:2'
|
||||
algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
|
||||
</file>]]></code>
|
||||
<p>The child elements of the <file/> element are as follows:</p>
|
||||
<table caption='File Description Elements'>
|
||||
<tr>
|
||||
<th>Element Name</th>
|
||||
<th>Description</th>
|
||||
<th>Example</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>date</td>
|
||||
<td>Timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;).</td>
|
||||
<td><tt>2015-07-26T21:46:00+01:00</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>dimensions</td>
|
||||
<td>Horizontal and vertical dimensions of image or video files, in pixels.</td>
|
||||
<td><tt>1920x1080</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>desc</td>
|
||||
<td>A human readable description of the file. Multiple <tt><desc/></tt> elements MAY be included if different xml:lang values are specified.</td>
|
||||
<td><tt>Picture of 24th XSF Summit</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>hash</td>
|
||||
<td>A hash of the file content, using the <tt><hash/></tt> element defined in &xep0300; and qualifed by the 'urn:xmpp:hashes:2' namespace. Multiple hashes MAY be included for hash agility.</td>
|
||||
<td><em>see specification</em></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>length</td>
|
||||
<td>Length of an audio or video file, in milliseconds.</td>
|
||||
<td><tt>63000</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>media-type</td>
|
||||
<td>The media type of the file content, which SHOULD be a valid MIME-TYPE as registered with &IANA; (specifically, as listed at <<link url='http://www.iana.org/assignments/media-types'>http://www.iana.org/assignments/media-types</link>>). If not specified, the content is assumed to be "application/octet-stream".</td>
|
||||
<td><tt>text/plain</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>name</td>
|
||||
<td>The name of the file. The name SHOULD NOT contain characters or character sequences that would be interpreted as a directory structure by the local file system (e.g. "/", "\", "../", etc.). If any such characters or character sequences are present (possibly because the local and remote file systems use different syntax for directory structure), they SHOULD be escaped (e.g., via percent-encoding) before using the name as part of any file system operation. See <link url='#security'>Security Considerations</link>.</td>
|
||||
<td><tt>text.txt</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>size</td>
|
||||
<td>The length of the file's content, in bytes.</td>
|
||||
<td><tt>6144</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>thumbnail</td>
|
||||
<td>A thumbnail element of the file, using the <thumbnail/> element defined in &xep0264; and qualified by the 'urn:xmpp:thumbs:1' namespace. Multiple thumbnails MAY be included for media type and size agility.</td>
|
||||
<td><em>see specification</em></td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
All child elements are OPTIONAL, however, specifications making use of the
|
||||
file metadata object MAY require providing some of these elements as part
|
||||
of their specification.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>
|
||||
Caution needs to be exercised when using the <tt><name/></tt> of the metadata
|
||||
to control any interaction with a file system. For example, a malicious
|
||||
user could request a file with <tt><name>/etc/passwd</name></tt> or
|
||||
include file system specific control patterns such as
|
||||
<tt><name>../../private.txt</name></tt> to try and access a sensitive
|
||||
file outside of the set of files intended to be shared. Or a malicious user
|
||||
could offer a file named <tt>/etc/passwd</tt> to try and trick the receiver into
|
||||
overwriting that or other sensitive files. Therefore, implementations
|
||||
SHOULD escape any file system path separators in the <tt><name/></tt> before
|
||||
using that value in any file system calls.
|
||||
</p>
|
||||
<p>
|
||||
It is RECOMMENDED for implementations to use the strongest hashing
|
||||
algorithm available to both parties. See &xep0300; for further discussion.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='ns'>
|
||||
<p>The ®ISTRAR; includes 'urn:xmpp:file:metadata:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:file:metadata:0</li>
|
||||
</ul>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to the authors of &xep0234; which heavily inspired this XEP.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
208
xep-0447.xml
Normal file
208
xep-0447.xml
Normal file
@ -0,0 +1,208 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!--
|
||||
Note to editor: Remove xep-file-metadata entity declared below and change all references from &xep-file-metadata; to respective &xepXXXX; to refeence file metadata element when moving to experimental.
|
||||
-->
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY xep-file-metadata "<span class='ref'><link url='./file-metadata.html'>File metadata element (XEP-xxxx)</link></span> <note>XEP-xxxx: File metadata element <<link url='./file-metadata.html'>https://xmpp.org/extensions/inbox/file-metadata.html</link>>.</note>" >
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stateless file sharing</title>
|
||||
<abstract>This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0447</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
<spec>XEP-xxxx</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>sfs</shortname>
|
||||
&larma;
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted by vote of Council on 2020-11-18.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2020-11-10</date>
|
||||
<initials>lmw</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
This is a reiteration on &xep0385; with some significant changes:
|
||||
</p>
|
||||
<ul>
|
||||
<li>No focus on media, generic for every file type.</li>
|
||||
<li>No mixed content, body is used for fallback only and not to transmit additional information.</li>
|
||||
<li>Using &xep-file-metadata;.</li>
|
||||
<li>Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers).</li>
|
||||
<li>Not relying on underspecified usage of &xep0372;.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<ul>
|
||||
<li>Do not require any server components for easier deployment</li>
|
||||
<li>Should work and enable a good UX in multi-user chats like &xep0045; and &xep0369;</li>
|
||||
<li>Should work great together with conversation synchronization protocols like &xep0280; and &xep0313;</li>
|
||||
<li>Reuse existing protocols for the actual transport of the data, i.e. &xep0234; or &xep0363;</li>
|
||||
<li>Guarantee file integrity</li>
|
||||
<li>Enable aggresive caching</li>
|
||||
<li>Provide users with metadata, e.g. file size, file type or thumbnail, to help them decide whether or not they want to load the file</li>
|
||||
<li>Support referring to third party hosting services</li>
|
||||
<li>Backwards compatibility with existing, widely-deployed protocols</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Use cases' anchor='usecases'>
|
||||
<section2 topic='Sharing a file' anchor='file-sharing'>
|
||||
<p>
|
||||
To share a file, a user sends a message stanza including <tt><file-sharing/></tt> to the inteded recipient contact or group.
|
||||
The <tt><file-sharing/></tt> element includes a <tt><file/></tt> metadata element as described in &xep-file-metadata; as well as a <tt><sources/></tt> element.
|
||||
The <tt><sources/></tt> element provides one or multiple sources that the receiving client may use to obtain the file.
|
||||
</p>
|
||||
<example caption='Sharing summit.jpg with juliet@shakespeare.lit'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
|
||||
<file-sharing xmlns='urn:xmpp:sfs:0'>
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>image/jpeg</media-type>
|
||||
<name>summit.jpg</name>
|
||||
<size>3032449</size>
|
||||
<dimension>4096x2160</dimension>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='id-blake2b256'>2AfMGH8O7UNPTvUVAM9aK13mpCY=</hash>
|
||||
<desc>Photo from the summit.</desc>
|
||||
<thumbnail xmlns='urn:xmpp:thumbs:1' uri='cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org' media-type='image/png' width='128' height='96'/>
|
||||
</file>
|
||||
<sources>
|
||||
<url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' />
|
||||
<jinglepub xmlns='urn:xmpp:jinglepub:1' from='romeo@montague.lit/resource' id='9559976B-3FBF-4E7E-B457-2DAA225972BB'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:file-transfer:5' />
|
||||
</jinglepub>
|
||||
</sources>
|
||||
</file-sharing>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>
|
||||
It is RECOMMENDED that the file metadata specifies name, media-type, size and one or multiple hash elements as described in &xep0300;.
|
||||
The hash elements provide end-to-end file integrity and allow efficient caching and flexible retrieval methods.
|
||||
</p>
|
||||
<p>
|
||||
The message MAY include a suitable fallback body.
|
||||
The fallback body MUST NOT include any information that is not also represented in <tt><file-sharing/></tt>.
|
||||
If the <tt><sources/></tt> element includes an <tt><url-data/></tt> element that can be represented as a single URL, adding a &xep0066; x-oob reference is RECOMMENDED for compatibility.
|
||||
</p>
|
||||
<example caption='Sharing summit.jpg with juliet@shakespeare.lit with fallback'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
|
||||
<file-sharing xmlns='urn:xmpp:sfs:0'>
|
||||
<!-- ... -->
|
||||
</file-sharing>
|
||||
<body>Photo from the summit: https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg</body>
|
||||
<x xmlns='jabber:x:oob'><url>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg</url></x>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>If the message has an empty body, it is RECOMMENDED to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.</p>
|
||||
<example caption='Sharing summit.jpg with juliet@shakespeare.lit without fallback'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
|
||||
<file-sharing xmlns='urn:xmpp:sfs:0'>
|
||||
<!-- ... -->
|
||||
</file-sharing>
|
||||
<store xmlns='urn:xmpp:hints' />
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Receiving a file' anchor='file-receive'>
|
||||
<p>
|
||||
On receive of a message including a <tt><file-sharing/></tt> element, the receiving entity SHOULD lookup in a local storage, whether the file with any of the proivded hashes has already been retrieved and is available.
|
||||
In that case no transfer needs to be initated and the cached file can be used instead.
|
||||
</p>
|
||||
<p>
|
||||
If the file is not available locally, the file can be obtained by one of the sources listed in the <tt><sources/></tt> element.
|
||||
If further sources have been attached (as described in <link url="#attach-source">Attaching a source</link>), the receiving entity may also try to obtain the file from any of those.
|
||||
</p>
|
||||
<p>
|
||||
When the source is an <tt><url-data/></tt> element as described in &xep0103;, the receiving entity MAY obtain the file by downloading it from the specified URL.
|
||||
If the URL uses HTTP or HTTPS and additional HTTP request information as specified in &xep0104; is provided, the receiving entity SHOULD use such information when obtaining the file.
|
||||
When sending and receiving files using <tt><url-data/></tt>, it is RECOMMENDED to prefer secure protocols (e.g. HTTPS, FTPS).
|
||||
Please read <link url="#security">security considerations</link> when implementing support for insecure URLs.
|
||||
</p>
|
||||
<p>
|
||||
When the source is a <tt><jingle-pub/></tt> element as described in &xep0358;, the receiving entity MAY obtain the file using the protocol described in &xep0358;.
|
||||
If a <tt><hash/></tt> is provided, the receiving entity MAY obtain the file by requesting it as described in &xep0234;.
|
||||
</p>
|
||||
<p>
|
||||
If sources of any other type are provided, clients MAY attempt to obtain the files from such sources.
|
||||
The details of obtaining such file are out of scope of this document.
|
||||
</p>
|
||||
<p>
|
||||
If the <tt><media-type/></tt> of the shared file is such that it can be displayed inline, the receiving entity MAY display the file inline.
|
||||
If no <tt><media-type/></tt> is provided or the <tt><media-type/></tt> indicates that the file can not be displayed inline, i.e. when the media type is <tt>application/octet-stream</tt>, the receiving entity SHOULD NOT display the file inline and instead offer to download it or save it on the users file system.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Attaching a source' anchor='attach-source'>
|
||||
<p class='box'>TODO: The following section relies on &xep0367;, however other methods to attach information to another message like the recently proposed &xep0422; might be suitable here as well. This is to be clarified before advancing to Draft.</p>
|
||||
<p>
|
||||
After a user shared a file using one entity and another entity in the conversation obtained it or found it in its local storage, that entity MAY announce that the file is now available with an additional source.
|
||||
This increases availability of the file in case the sender goes offline before all the intended recipients were able to fetch the file. It also allows for peer-to-peer file distribution in group chats.
|
||||
</p>
|
||||
<p>
|
||||
The entity MUST NOT announce itself as an additional source before verifying that <em>all</em> hashes provided match the hash of the file.
|
||||
If no hashes are provided, the entity SHOULD NOT announce itself as an additional source.
|
||||
</p>
|
||||
<p>The attaching itself is performed by sending a message including a <tt><sources></tt> element with further sources using the protocol described in &xep0367;.</p>
|
||||
<p>Depending on the lifetime of the newly attached source, it may be useful to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.</p>
|
||||
<example caption='romeo@montague.lit/resource2 attaches itself as an additional source for the file'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource2'>
|
||||
<attach-to id='sharing-a-file' xmlns='urn:xmpp:message-attaching:1'/>
|
||||
<sources xmlns='urn:xmpp:sfs:0'>
|
||||
<jinglepub xmlns='urn:xmpp:jinglepub:1' from='romeo@montague.lit/resource2' id='9559976B-3FBF-4E7E-B457-2DAA225972BB'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:file-transfer:5' />
|
||||
</jinglepub>
|
||||
</sources>
|
||||
<store xmlns='urn:xmpp:hints' />
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>
|
||||
If a <tt><hash/></tt> using any supported algorithm is provided, the receiving client SHOULD verify that the <tt><hash/></tt> of the announced file matches the obained file before presenting it to the user.
|
||||
If no <tt><hash/></tt> is provided or the <tt><hash/></tt> elements provided use unsupported algorithms, receiving clients MUST ignore any attached sources from other senders and only obtain the file from the sources announced by the original sender.
|
||||
If no <tt><hash/></tt> is provided or the <tt><hash/></tt> elements provided use unsupported algorithms, receiving clients MUST ignore any sources that use unsecure protocols (e.g. HTTP without TLS).
|
||||
</p>
|
||||
<p>
|
||||
For most methods of transferring a file proposed through the <tt><sources/></tt> element, obtaining files requires revealing private information like IP addresses to the sending user or third-parties.
|
||||
Sources that do not require revealing private information to untrusted entities SHOULD be preferred by receiving entitites.
|
||||
Receiving entities SHOULD ask users for confirmation before obtaining a file, if doing so would require revealing private information to untrusted entities.
|
||||
If the protocol that is used when obtaining the file is not secure (e.g. HTTP without TLS), this SHOULD be considered as if the protocol reveals private information.
|
||||
</p>
|
||||
<p>
|
||||
The security considerations of &xep-file-metadata; apply.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='ns'>
|
||||
<p>The ®ISTRAR; includes 'urn:xmpp:sfs:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:sfs:0</li>
|
||||
</ul>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to the authors of &xep0385; which heavily inspired this XEP.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
166
xep-0448.xml
Normal file
166
xep-0448.xml
Normal file
@ -0,0 +1,166 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!--
|
||||
Note to editor: Remove xep-sfs entity declared below and change all references from &xep-sfs; to respective &xepXXXX; to refeence sfs when moving to experimental.
|
||||
-->
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY xep-sfs "<span class='ref'><link url='./sfs.html'>Stateless file sharing (XEP-xxxx)</link></span> <note>XEP-xxxx: Stateless file sharing <<link url='./sfs.html'>https://xmpp.org/extensions/inbox/sfs.html</link>>.</note>" >
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Encryption for stateless file sharing</title>
|
||||
<abstract>This specification provides a protocol for sharing encrypted files using the stateless file sharing protocol (XEP-xxxx).</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0448</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
<spec>XEP-xxxx</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>esfs</shortname>
|
||||
&larma;
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted by vote of Council on 2020-11-18.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2020-11-10</date>
|
||||
<initials>lmw</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
End-to-end encrypted messaging is a popular feature within the community.
|
||||
Various protocols like &xep0373; or &xep0384; have been proposed to allow sending encrypted messages.
|
||||
&xep0343; and &xep0391; specify protocols for establishing an encrypted transport using Jingle to share files using &xep0234;.
|
||||
</p>
|
||||
<p>
|
||||
&xep-sfs; describes a protocol that can be used to share files, previously uploaded using &xep0363;, but lacks means of encrypting files.
|
||||
This leaves files uploaded using &xep0363; without any standardized means of encrypting them.
|
||||
</p>
|
||||
<p>This XEP describes a protocol building on top of &xep-sfs; to allow encrypting files.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<ul>
|
||||
<li>Make use of existing protocols for end-to-end encryption (&xep0373; and &xep0420;)</li>
|
||||
<li>Reuse existing protocols for the actual transport of the data</li>
|
||||
<li>Allow caching and forwarding without being required to decrypt the file</li>
|
||||
<li>Backwards compatibility with existing, widely-deployed protocols<note>There is a widely-deployed protocol for encrypted file sharing known as "OMEMO media sharing" or "aesgcm-links" that was never accepted as a XEP. While backwards compatibility with such non-standard is not a maxime of the XSF, it was still considered during the design of this protocol.</note></li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<p>
|
||||
This protocol is only meaningful for end-to-end encrypted file sharing when transported as end-to-end encrypted XML, like it's possible using &xep0420;.
|
||||
However, usage without such end-to-end encryption still has its usecase, as it allows sharing files through untrusted intermediaries for as long as the intermediary XMPP servers, if any, are trusted.
|
||||
</p>
|
||||
<p class='box'>Note: To make the examples in this document more readable, no end-to-end encryption is used.</p>
|
||||
<section2 topic='Sharing a file' anchor='file-sharing'>
|
||||
<p>
|
||||
Before sharing the file, the sending entity MUST create random symmetric private key and initialization vector (IV) as required by the selected encryption cipher (see <link url='#ciphers'>Ciphers</link>). The file is then encrypted using selected encryption cipher and the generated key and IV. After this it can be uploaded using &xep0363; or prepared for any other means of file sharing.
|
||||
</p>
|
||||
<p>
|
||||
The file is then shared using the protocol described in &xep-sfs;.
|
||||
The <tt><file/></tt> metadata element still refers to the original file, i.e. it describes the original file name, size and hashes. The <tt><size/></tt> element and one or multiple <tt><hash/></tt> elements are REQUIRED when sending encrypted files.
|
||||
</p>
|
||||
<p>
|
||||
For the encrypted file, a source is added as an <tt><encrypted/></tt> element to the <tt><sources/></tt>. It carries an attribute <tt>cipher</tt> with the namespace of the encryption cipher being used. The <tt><encrypted/></tt> element contains a <tt><key/></tt> and an <tt><iv/></tt> element, containing both values as Base64-encoded strings. The <tt><encrypted/></tt> element MAY also include <tt><hash/></tt> elements as described in &xep0300;, referring to the hash of the encrypted file. At last, the <tt><encrypted/></tt> element also includes another <tt><sources/></tt> element as described in &xep-sfs;, specifying sources to obtain the encrypted file.
|
||||
The outer <tt><sources/></tt> may contain additional sources that directly allow for end-to-end encrypted file transfers, for example &xep0234; using &xep0391;.
|
||||
</p>
|
||||
<example caption='Sharing summit.jpg with juliet@shakespeare.lit using encryption'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
|
||||
<file-sharing xmlns='urn:xmpp:sfs:0'>
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>image/jpeg</media-type>
|
||||
<name>summit.jpg</name>
|
||||
<size>3032449</size>
|
||||
<dimension>4096x2160</dimension>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='id-blake2b256'>2AfMGH8O7UNPTvUVAM9aK13mpCY=</hash>
|
||||
<desc>Photo from the summit.</desc>
|
||||
<thumbnail xmlns='urn:xmpp:thumbs:1' uri='cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org' media-type='image/png' width='128' height='96'/>
|
||||
</file>
|
||||
<sources>
|
||||
<encrypted xmlns='urn:xmpp:esfs:0' cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding:0'>
|
||||
<key>SuRJ2agVm/pQbJQlPq/B23Xt1YOOJCcEGJA5HrcYOGQ=</key>
|
||||
<iv>T8RDMBaiqn6Ci4Nw</iv>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>BgKI2gp2kNCRsARNvhFmw5kFf9BBo2pTbV2D8XHTMWI=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='id-blake2b256'>id4cnqqy9/ssfCkM4vYSkiXXrlE=</hash>
|
||||
<sources xmlns='urn:xmpp:sfs:0'>
|
||||
<url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/encrypted.jpg' />
|
||||
</sources>
|
||||
</encrypted>
|
||||
<jinglepub xmlns='urn:xmpp:jinglepub:1' from='romeo@montague.lit/resource' id='9559976B-3FBF-4E7E-B457-2DAA225972BB'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:file-transfer:5' />
|
||||
</jinglepub>
|
||||
</sources>
|
||||
</file-sharing>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Receiving a file' anchor='file-receive'>
|
||||
<p>On receive of a message including a <tt><file-sharing/></tt> element, that has an <tt><encrypted/></tt> element in its sources, normal processing as described in &xep-sfs; applies.</p>
|
||||
<p>
|
||||
When the receiving entity tries to obtain the file from the source described by the <tt><encrypted/></tt> element, it will try to obtain any of its inner sources instead.
|
||||
On success, it decrypts the obtained file using the encryption cipher, private key and IV provided.
|
||||
If the resulting file is larger than the number of bytes specified in the <tt><size/></tt> metadata element, the additional bytes are cut off.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Attaching a source' anchor='attach-source'>
|
||||
<p>
|
||||
The protocol to attach a source described in &xep-sfs; can also be used to attach encrypted sources.
|
||||
After receiving a file using encrypted means, it is RECOMMENDED to only attach additional sources that support encryption.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Ciphers' anchor='ciphers'>
|
||||
<p class='box'>Note The following table was copied from &xep0391;.</p>
|
||||
<p>In order to encrypt the file, the sending entity must transmit a cipher key to the responder. There are multiple options available:</p>
|
||||
<table caption='Available ciphers, configurations and their namespaces'>
|
||||
<tr>
|
||||
<th>Namespace</th>
|
||||
<th>Type</th>
|
||||
<th>Length (bits)</th>
|
||||
<th>Parameters</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>urn:xmpp:ciphers:aes-128-gcm-nopadding:0</td>
|
||||
<td>AES</td>
|
||||
<td>Key: 128, IV: 96</td>
|
||||
<td>GCM/NoPadding</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>urn:xmpp:ciphers:aes-256-gcm-nopadding:0</td>
|
||||
<td>AES</td>
|
||||
<td>Key: 256, IV: 96</td>
|
||||
<td>GCM/NoPadding</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>For compatibility reasons, it is RECOMMENDED to append the GCM authentication tag to the uploaded file when using any AES cipher with GCM. The GCM authentication tag is not needed when using the protocol described in this document as a hash of the resulting file is transported independently.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>Yes.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='ns'>
|
||||
<p>The ®ISTRAR; includes 'urn:xmpp:esfs:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:esfs:0</li>
|
||||
</ul>
|
||||
</section2>
|
||||
</section1>
|
||||
</xep>
|
||||
238
xep-0449.xml
Normal file
238
xep-0449.xml
Normal file
@ -0,0 +1,238 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!--
|
||||
Note to editor:
|
||||
- Remove xep-sfs entity declared below and change all references from &xep-sfs; to respective &xepXXXX; to refeence sfs when moving to experimental.
|
||||
- Remove xep-file-metadata entity declared below and change all references from &xep-file-metadata; to respective &xepXXXX; to refeence file metadata when moving to experimental.
|
||||
-->
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY xep-file-metadata "<span class='ref'><link url='./file-metadata.html'>File metadata element (XEP-xxxx)</link></span> <note>XEP-xxxx: File metadata element <<link url='./file-metadata.html'>https://xmpp.org/extensions/inbox/file-metadata.html</link>>.</note>" >
|
||||
<!ENTITY xep-sfs "<span class='ref'><link url='./sfs.html'>Stateless file sharing (XEP-xxxx)</link></span> <note>XEP-xxxx: Stateless file sharing <<link url='./sfs.html'>https://xmpp.org/extensions/inbox/sfs.html</link>>.</note>" >
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
<!ENTITY sepl4 "0x1f (ASCII Unit Separator)">
|
||||
<!ENTITY sepl3 "0x1e (ASCII Record Separator)">
|
||||
<!ENTITY sepl2 "0x1d (ASCII Group Separator)">
|
||||
<!ENTITY sepl1 "0x1c (ASCII File Separator)">
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stickers</title>
|
||||
<abstract>This specification provides a protocol to send stickers and to create and share sticker packs.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0449</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>stickers</shortname>
|
||||
&larma;
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-11-24</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted by vote of Council on 2020-11-18.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>lmw</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Stickers<note><em>Sticker (messaging)</em> on Wikipedia <<link url='https://en.wikipedia.org/wiki/Sticker_(messaging)'>https://en.wikipedia.org/wiki/Sticker_(messaging)</link>>.</note> are images or short animations that often represent an emoticon or an action. They are increasingly used in private messaging in the last years, especially on mobile phone apps. Stickers can be more nuanced and expressive than emoticons. They can be used to convey emotions or tell stories in a fun and easy way.</p>
|
||||
<p>Recently, demand to implement stickers, including their social feature of sharing sticker packs arised within the XMPP community. This specification is to fulfill this demand.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<ul>
|
||||
<li>Do not require additional server components for easier deployment</li>
|
||||
<li>Compatibility with non-graphical user interfaces (terminals, etc)</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<dl>
|
||||
<di><dt>Sticker</dt><dd>Emoticon-like picture</dd></di>
|
||||
<di><dt>Sticker pack</dt><dd>Collection of stickers, typically devoted to a specific theme or with all stickers created by the same author</dd></di>
|
||||
</dl>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Creating a sticker pack' anchor='create'>
|
||||
<p>
|
||||
Sticker packs are stored on pubsub nodes.
|
||||
They SHOULD be located at a personal eventing (PEP) node named "urn:xmpp:stickers:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account.
|
||||
The pubsub node's access model SHOULD be set to 'open', so that other users can fetch sticker packs.
|
||||
</p>
|
||||
<section3 topic='Sticker pack pubsub item' anchor='pubsub-item'>
|
||||
<p>
|
||||
Each sticker pack is one item on the pubsub node consisting of a <tt><pack/></tt> element.
|
||||
</p>
|
||||
<p>
|
||||
The <tt><pack/></tt> element includes elements <tt><name/></tt> and <tt><summary/></tt> to announce a name and summary of the sticker pack that can be displayed to users, respectively.
|
||||
The summary MAY contain copyright and license information in user-readable format.
|
||||
Multiple <tt><name/></tt> and <tt><summary/></tt> elements MAY be included given that no two elements of same name specify the same <tt>xml:lang</tt>.
|
||||
</p>
|
||||
<p>
|
||||
The <tt><pack/></tt> element MAY include a <tt><restricted/></tt> element to indicate that this sticker pack may not be used or imported by other users.
|
||||
</p>
|
||||
<p>
|
||||
The <tt><pack/></tt> element contains one or more <tt><item/></tt> elements that include details on the stickers in the pack. Each <tt><item/></tt> element has <tt><file/></tt> element as described in &xep-file-metadata;. The metadata MUST include one or multiple <tt><hash/></tt> elements as described in &xep0300;. All stickers in a pack MUST use the same algorithm for their <tt><hash/></tt> elements. The metadata MUST include one <tt><desc/></tt> element that is not qualified by a <tt>xml:lang</tt> attribute and describes the textual fallback (often an emoji or a sequence of emojis) of the sticker. Each <tt><item/></tt> element further has a <tt><sources/></tt> element as described in &xep-sfs; describing how to retrieve the image file of the sticker. Each <tt><item/></tt> element MAY include one or more <tt><suggest/></tt> elements that include a text that clients may replace with the sticker. <tt><suggest/></tt> elements MAY have an <tt>xml:lang</tt> attribute.
|
||||
</p>
|
||||
<p>
|
||||
Finally, the <tt><pack/></tt> element includes a single <tt><hash/></tt> element as described in &xep0300;, specifying the hash of the sticker pack. See <link url='#pack-hash'>next section</link> on how such hash is generated.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Sticker pack hash calculation' anchor='pack-hash'>
|
||||
<p>Each sticker pack has a unique ID, which is used as the pubsub item's id. This ID is derived from a hash of significant information from a <tt><pack/></tt> element as outlined in this section.</p>
|
||||
<ol>
|
||||
<li><p>Processing <tt><name/></tt> and <tt><summary/></tt> elements:</p>
|
||||
<ol>
|
||||
<li><p>For each <tt><name/></tt> or <tt><summary/></tt> element:</p>
|
||||
<ol>
|
||||
<li>Encode the character data of element name (<tt>name</tt> or <tt>summary</tt>), <tt>xml:lang</tt> attribute value and content.</li>
|
||||
<li>Append an octet of value &sepl4; to each resulting octet string.</li>
|
||||
<li>Join the resulting octet strings together, in the order of element name, <tt>xml:lang</tt> attribute and content, resulting in a single octet string for the <tt><name/></tt> or <tt><summary/></tt> element.</li>
|
||||
<li>Append an octet of value &sepl3;.</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li>Join the resulting octet strings together, ordered from lesser to greater.</li>
|
||||
<li>Append an octet of value &sepl1;.</li>
|
||||
</ol>
|
||||
<p>The result of this step is referenced as <em>Meta string</em> later.</p>
|
||||
</li>
|
||||
<li><p>Processing <tt><item/></tt> elements:</p>
|
||||
<ol>
|
||||
<li><p>For each <tt><item/></tt> element:</p>
|
||||
<ol>
|
||||
<li>Encode the character data of <tt><file/></tt>'s <tt><desc/></tt> content.</li>
|
||||
<li>Append an octet of value &sepl3; to the resulting octet string.</li>
|
||||
<li><p>For each of <tt><hash/></tt> element in <tt><file/></tt>:</p>
|
||||
<ol>
|
||||
<li>Encode the character data of <tt>algo</tt> attribute and content.</li>
|
||||
<li>Append an octet of value &sepl4; to the resulting octet strings.</li>
|
||||
<li>Join the resulting octet strings together, in the order of <tt>algo</tt> attribute and content, resulting in a single octet string for the <tt><hash/></tt> element.</li>
|
||||
<li>Append an octet of value &sepl3;.</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li>Join the resulting octet strings together, in the order of <tt><file/></tt>'s <tt><desc/></tt> content first and then all <tt><hash/></tt> elements ordered from lesser to greater.</li>
|
||||
<li>Append an octet of value &sepl2;.</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li>Join the resulting octet strings together, ordered from lesser to greater.</li>
|
||||
<li>Append an octet of value &sepl1;.</li>
|
||||
</ol>
|
||||
<p>The result of this step is referenced as <em>Stickers string</em> later.</p>
|
||||
</li>
|
||||
<li>Join the <em>Meta String</em> and <em>Stickers String</em> together, in this order.</li>
|
||||
<li>Hash the resulting string using the algorithm choosen for the sticker pack.</li>
|
||||
</ol>
|
||||
<p>The ID of the sticker pack is dervied by taking the first 144 bit of the hash and encode it using Base64. This is equivalent to the first 24 characters of the Base64 encoded content of the <tt><hash/></tt> element.</p>
|
||||
</section3>
|
||||
<example caption='Publish a new sticker pack'><![CDATA[
|
||||
<iq from='romeo@montague.lit/pda'
|
||||
id='pub1'
|
||||
to='romeo@montague.lit'
|
||||
type='set'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='urn:xmpp:stickers:0'>
|
||||
<item id='EpRv28DHHzFrE4zd+xaNpVb4'>
|
||||
<pack xmlns='urn:xmpp:stickers:0'>
|
||||
<name>Marsey the Cat</name>
|
||||
<summary>Be cute or be cynical, this little kitten works both ways.</summary>
|
||||
<item>
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>image/png</media-type>
|
||||
<desc>👍</desc>
|
||||
<size>71045</size>
|
||||
<dimension>512x512</dimension>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha-256'>0AdP8lJOWJrugSKOIAqfEKqFatIpG5JBCjjxY253ojQ=</hash>
|
||||
</file>
|
||||
<sources xmlns='urn:xmpp:sfs:0'>
|
||||
<url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/51078299-d071-46e1-b6d3-3de4a8ab67d6/sticker_marsey_thumbs_up.png' />
|
||||
</sources>
|
||||
<suggest>+1</suggest>
|
||||
</item>
|
||||
<item>
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>image/png</media-type>
|
||||
<desc>😘</desc>
|
||||
<size>67016</size>
|
||||
<dimension>512x512</dimension>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha-256'>gw+6xdCgOcvCYSKuQNrXH33lV9NMzuDf/s0huByCDsY=</hash>
|
||||
</file>
|
||||
<sources xmlns='urn:xmpp:sfs:0'>
|
||||
<url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/51078299-d071-46e1-b6d3-3de4a8ab67d6/sticker_marsey_kiss.png' />
|
||||
</sources>
|
||||
</item>
|
||||
<!-- ... -->
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha-256'>EpRv28DHHzFrE4zd+xaNpVb4jbu4s74XtioExNjQzZ0=</hash>
|
||||
</pack>
|
||||
</item>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Sending a sticker' anchor='send'>
|
||||
<p>The sending entity uses &xep-sfs; to send the image file from the sticker pack. The <tt><item/></tt>'s <tt><file/></tt> and <tt><sources/></tt> elements from the sticker pack are used as a template. The sending entity MAY add additional <tt><hash/></tt> elements or sources.</p>
|
||||
<p>Additionally, the sending entity adds an element <tt><sticker/></tt> to the message. This element carries an attribute <tt>pack</tt> referring to the id of the pubsub item carrying the sticker pack. If the sticker pack resides on a pubsub item other than the senders personal eventing (PEP) node named "urn:xmpp:stickers:0", the sending entity must add additional attributes <tt>jid</tt> and <tt>node</tt>, referring to the jid of the pubsub node and the name of the node, respectively.</p>
|
||||
<p>The sending entity SHOULD use the <tt><file/></tt>'s <tt><desc/></tt> content as the message body, except if the sticker was selected based on a suggestion, in which case the content of the corresponding <tt><suggest/></tt> SHOULD be used.</p>
|
||||
<example caption='Sending a sticker'><![CDATA[
|
||||
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/pda' id='sharing-a-file'>
|
||||
<body>😘</body>
|
||||
<sticker xmlns='urn:xmpp:stickers:0' pack='EpRv28DHHzFrE4zd+xaNpVb4' />
|
||||
<file-sharing xmlns='urn:xmpp:sfs:0'>
|
||||
<file xmlns='urn:xmpp:file:metadata:0'>
|
||||
<media-type>image/png</media-type>
|
||||
<desc>😘</desc>
|
||||
<size>67016</size>
|
||||
<dimension>512x512</dimension>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha-256'>gw+6xdCgOcvCYSKuQNrXH33lV9NMzuDf/s0huByCDsY=</hash>
|
||||
</file>
|
||||
<sources>
|
||||
<url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/51078299-d071-46e1-b6d3-3de4a8ab67d6/sticker_marsey_kiss.png' />
|
||||
</sources>
|
||||
</file-sharing>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Receiving a sticker' anchor='receive'>
|
||||
<p>When receiving a message with a <tt><sticker/></tt> element, the receiving entity SHOULD consider the message and the <tt><file-sharing/></tt> element as a sticker.</p>
|
||||
<p>When receiving a sticker, the receiving entity may display the stickers image file inline or display the textual representation in the <tt><desc/></tt> element. The receiving entity SHOULD NOT display the received sticker only as a downloadable file.</p>
|
||||
</section2>
|
||||
<section2 topic='Importing a sticker pack' anchor='import'>
|
||||
<p>When receiving a sticker or any other reference to a sticker pack, the receiving entity may allow the user to import such sticker pack. The receiving entity SHOULD NOT offer to import a sticker pack that has a <tt><restricted/></tt> element.</p>
|
||||
<p>When importing a sticker pack, the entity SHOULD make all files that are part of the sticker pack locally available. The entity SHOULD duplicate the pubsub item from its original source to the users personal eventing (PEP) node named "urn:xmpp:stickers:0", preserving the pack id. The entity MAY remove any of the sources provided, and MAY make an effort to make the files available at additional sources, e.g. by using &xep0363;.</p>
|
||||
</section2>
|
||||
<section2 topic='Sharing a sticker pack' anchor='share'>
|
||||
<p>After creating or importing a sticker pack, it can be shared using an <tt>xmpp:</tt>-uri as described in &xep0060;.</p>
|
||||
<p>When handling this URI, the entity SHOULD display a preview of the sticker pack and allow importing it as described above.</p>
|
||||
<example caption='Sticker pack URI'>xmpp:romeo@montague.lit?pubsub;action=retrieve;node=urn:xmpp:stickers:0;item=EpRv28DHHzFrE4zd%2BxaNpVb4</example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Accessibility Considerations' anchor='access'>
|
||||
<p>Flickering, flashing or blinking stickers can induce seizures or other incapacitating physical reactions. It is RECOMMENDED that clients that support stickers have an option to disable animations and/or stickers entirely.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>
|
||||
The security considerations of &xep-sfs; apply.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='ns'>
|
||||
<p>The ®ISTRAR; includes 'urn:xmpp:stickers:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:stickers:0</li>
|
||||
</ul>
|
||||
</section2>
|
||||
</section1>
|
||||
</xep>
|
||||
7
xep.ent
7
xep.ent
@ -1607,3 +1607,10 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
|
||||
<!ENTITY xep0440 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0440.html'>SASL Channel-Binding Type Capability (XEP-0440)</link></span> <note>XEP-0440: SASL Channel-Binding Type Capability <<link url='https://xmpp.org/extensions/xep-0440.html'>https://xmpp.org/extensions/xep-0440.html</link>>.</note>" >
|
||||
<!ENTITY xep0441 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0441.html'>Message Archive Management Preferences (XEP-0441)</link></span> <note>XEP-0441: Message Archive Management Preferences <<link url='https://xmpp.org/extensions/xep-0441.html'>https://xmpp.org/extensions/xep-0441.html</link>>.</note>" >
|
||||
<!ENTITY xep0442 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0442.html'>Pubsub Message Archive Management (XEP-0442)</link></span> <note>XEP-0442: Pubsub Message Archive Management <<link url='https://xmpp.org/extensions/xep-0442.html'>https://xmpp.org/extensions/xep-0442.html</link>>.</note>" >
|
||||
<!ENTITY xep0443 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0443.html'>XMPP Compliance Suites 2021 (XEP-0443)</link></span> <note>XEP-0443: XMPP Compliance Suites 2021 <<link url='https://xmpp.org/extensions/xep-0443.html'>https://xmpp.org/extensions/xep-0443.html</link>>.</note>" >
|
||||
<!ENTITY xep0444 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0444.html'>Message Reactions (XEP-0444)</link></span> <note>XEP-0444: Message Reactions <<link url='https://xmpp.org/extensions/xep-0444.html'>https://xmpp.org/extensions/xep-0444.html</link>>.</note>" >
|
||||
<!ENTITY xep0445 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0445.html'>Pre-Authenticated In-Band Registration (XEP-0445)</link></span> <note>XEP-0445: Pre-Authenticated In-Band Registration <<link url='https://xmpp.org/extensions/xep-0445.html'>https://xmpp.org/extensions/xep-0445.html</link>>.</note>" >
|
||||
<!ENTITY xep0446 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0446.html'>File metadata element (XEP-0446)</link></span> <note>XEP-0446: File metadata element <<link url='https://xmpp.org/extensions/xep-0446.html'>https://xmpp.org/extensions/xep-0446.html</link>>.</note>" >
|
||||
<!ENTITY xep0447 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0447.html'>Stateless file sharing (XEP-0447)</link></span> <note>XEP-0447: Stateless file sharing <<link url='https://xmpp.org/extensions/xep-0447.html'>https://xmpp.org/extensions/xep-0447.html</link>>.</note>" >
|
||||
<!ENTITY xep0448 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0448.html'>Encryption for stateless file sharing (XEP-0448)</link></span> <note>XEP-0448: Encryption for stateless file sharing <<link url='https://xmpp.org/extensions/xep-0448.html'>https://xmpp.org/extensions/xep-0448.html</link>>.</note>" >
|
||||
<!ENTITY xep0449 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0449.html'>Stickers (XEP-0449)</link></span> <note>XEP-0449: Stickers <<link url='https://xmpp.org/extensions/xep-0449.html'>https://xmpp.org/extensions/xep-0449.html</link>>.</note>" >
|
||||
|
||||
Loading…
Reference in New Issue
Block a user