XEP-0447: Stateless file sharing

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.
Author
Marvin Wißfeld
Copyright
© 2020 – 2023 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
Type
Standards Track
Version
0.3.0 (2023-06-24)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

This is a reiteration on Stateless Inline Media Sharing (XEP-0385) [1] with some significant changes:

2. Requirements

3. Basic use cases

3.1 Sharing a file

To share a file, a user sends a message stanza including <file-sharing/> to the inteded recipient contact or group. The <file-sharing/> element MAY have a disposition attribute with a value of either attachment or inline and MAY have an id attribute. The <file-sharing/> element includes a <file/> metadata element as described in File metadata element (XEP-0446) [2] and MAY include a <sources/> element. The <sources/> element provides one or multiple sources that the receiving client may use to obtain the file.

Example 1. Sharing summit.jpg with juliet@shakespeare.lit
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <media-type>image/jpeg</media-type>
      <name>summit.jpg</name>
      <size>3032449</size>
      <width>4096</width>
      <height>2160</height>
      <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>

It is RECOMMENDED that the file metadata specifies name, media-type, size and one or multiple hash elements as described in Use of Cryptographic Hash Functions in XMPP (XEP-0300) [10]. The hash elements provide end-to-end file integrity and allow efficient caching and flexible retrieval methods.

The message MAY include a suitable fallback body. When doing so, an appropriate Fallback Indication (XEP-0428) [11] <fallback/> indicator with for set to urn:xmpp:sfs:0 MUST be added. The fallback body MUST NOT include any information that is not also represented in <file-sharing/>. If the <sources/> element includes an <url-data/> element that can be represented as a single URL, adding a Out-of-Band Data (XEP-0066) [12] x-oob reference is RECOMMENDED for compatibility.

Example 2. Sharing summit.jpg with juliet@shakespeare.lit with fallback
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline'>
    <!-- ... -->
  </file-sharing>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>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>

If the message has an empty body, it is RECOMMENDED to add a message processing hint, see Message Processing Hints (XEP-0334) [13], to indicate the message to be stored in message stores like Message Archive Management (XEP-0313) [7].

Example 3. Sharing summit.jpg with juliet@shakespeare.lit without fallback
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline'>
    <!-- ... -->
  </file-sharing>
  <store xmlns='urn:xmpp:hints' />
</message>

3.2 Receiving a file

On receive of a message including a <file-sharing/> 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.

If the file is not available locally, the file can be obtained by one of the sources listed in the <sources/> element. If further sources have been attached (as described in Attaching a source), the receiving entity may also try to obtain the file from any of those. If no <sources/> element is included with the message containing the <file-sharing/> element, the receiving entity SHOULD consider the file transfer pending and expect an attached source later.

The receiving entity SHOULD NOT fetch the file without prior user interaction if the disposition attribute is set to attachment. The receiving entity MAY fetch the file without prior user interaction otherwise, but when doing so, user's privacy, security (see Security Considerations) and network constraints should be considered.

When the source is an <url-data/> element as described in URL Address Information (XEP-0103) [14], 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 HTTP Scheme for URL Data (XEP-0104) [15] is provided, the receiving entity SHOULD use such information when obtaining the file. When sending and receiving files using <url-data/>, it is RECOMMENDED to prefer secure protocols (e.g. HTTPS, FTPS). Please read security considerations when implementing support for insecure URLs.

When the source is a <jingle-pub/> element as described in Publishing Available Jingle Sessions (XEP-0358) [16], the receiving entity MAY obtain the file using the protocol described in Publishing Available Jingle Sessions (XEP-0358) [16]. If a <hash/> is provided, the receiving entity MAY obtain the file by requesting it as described in Jingle File Transfer (XEP-0234) [8].

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.

The intended method to provide or display a file to the user depends on the disposition attribute, <media-type/> and file type support of the receiving entity:

3.3 Attaching a source

TODO: The following section relies on Message Attaching (XEP-0367) [17], however other methods to attach information to another message like the recently proposed Message Fastening (XEP-0422) [18] might be suitable here as well. This is to be clarified before advancing to Draft.

After a user shared a file using one entity and another entity in the conversation obtained it, found it in its local storage or knows a remote location that provides the same file, 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.

The entity MUST NOT announce itself as an additional source before verifying that all hashes provided match the hash of the file. If no hashes are provided, the entity SHOULD NOT announce itself as an additional source.

The attaching itself is performed by sending a message including a <sources> element with further sources using the protocol described in Message Attaching (XEP-0367) [17]. If the <file-sharing/> element to attach to had an id attribute, the <sources> element MUST also have an id attribute with the same value.

Depending on the lifetime of the newly attached source, it may be useful to add a message processing hint, see Message Processing Hints (XEP-0334) [13], to indicate the message to be stored in message stores like Message Archive Management (XEP-0313) [7].

Example 4. romeo@montague.lit/resource2 attaches itself as an additional source for the file
<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>

If the file was originally shared without a <sources/> element, the sending entity SHOULD attach a file source at a later point. For example, the sending entity may send a message with a <file-sharing/> element without a <sources/> element, when it starts uploading a file to the server (using HTTP File Upload (XEP-0363) [9]) and then attach the http source as soon as the upload is finished.

If the file was originally shared without a suitable fallback body, e.g. because the file was not yet uploaded at the time, the source attaching message MAY include a suitable fallback body. When doing so, an appropriate Fallback Indication (XEP-0428) [11] <fallback/> indicator with for set to urn:xmpp:sfs:0 MUST be added. The fallback body MUST NOT include any information that is not also represented in <sources/>. If the <sources/> element includes an <url-data/> element that can be represented as a single URL, adding a Out-of-Band Data (XEP-0066) [12] x-oob reference is RECOMMENDED for compatibility.

Example 5. Sharing a file and attaching the primary source for the file later, including a fallback body.
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline' id='file-sharing-id'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <media-type>image/jpeg</media-type>
      <name>summit.jpg</name>
      <size>3032449</size>
      <width>4096</width>
      <height>2160</height>
      <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>
  </file-sharing>
</message>

<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource'>
  <attach-to id='sharing-a-file' xmlns='urn:xmpp:message-attaching:1'/>
  <sources xmlns='urn:xmpp:sfs:0' id='file-sharing-id'>
    <url-data xmlns='http://jabber.org/protocol/url-data' target='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' />
  </sources>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>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>

4. Advanced use cases

4.1 Sharing a file with additional body

When sharing files, the sending entity MAY want to include an additional textual message with the file share. To do so, the sending entity SHOULD add such textual message in the body of the message that contains the <file-sharing/> element.

If a <file-sharing/> message includes a textual body, it MAY also include a fallback in that body, that MUST be annotated using an appropriate Fallback Indication (XEP-0428) [11] <fallback/> indicator with for set to urn:xmpp:sfs:0. However, in this case it is RECOMMENDED to use a source attaching message with a fallback body. This allows to send messages in a way that is still understood well by legacy clients.

Example 6. Sharing a file with additional body and attaching a source with fallback
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <body>Summit was great, check out this cool photo of everyone.</body>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <media-type>image/jpeg</media-type>
      <name>summit.jpg</name>
      <size>3032449</size>
      <width>4096</width>
      <height>2160</height>
      <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>
  </file-sharing>
</message>

<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='adding-the-source'>
  <attach-to id='sharing-a-file' xmlns='urn:xmpp:message-attaching:1'/>
  <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/summit.jpg' />
  </sources>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>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>

4.2 Sharing multiple files

When sharing files, the sending entity MAY want to share multiple files within a single message. To do so, the sending entity SHOULD add multiple <file-sharing/> elements in a single message. It MUST add an id attribute with differing values to each of these <file-sharing/> elements.

When sharing multiple files, it is RECOMMENDED to attach the sources of each file in an individual message. When doing so, it is RECOMMENDED to include appropriate fallbacks to the source attaching messages. This allows to send multiple files in a way that is still understood well by legacy clients.

Example 7. Sharing multiple files and attaching sources with fallback
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-files'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline' id='photo1.jpg'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <name>photo1.jpg</name>
    </file>
  </file-sharing>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline' id='photo2.jpg'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <name>photo2.jpg</name>
    </file>
  </file-sharing>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline' id='photo3.jpg'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <name>photo3.jpg</name>
    </file>
  </file-sharing>
</message>

<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='adding-photo1'>
  <attach-to id='sharing-files' xmlns='urn:xmpp:message-attaching:1'/>
  <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/photo1.jpg' />
  </sources>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo1.jpg</body>
  <x xmlns='jabber:x:oob'><url>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo1.jpg</url></x>
</message>

<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='adding-photo2'>
  <attach-to id='sharing-files' xmlns='urn:xmpp:message-attaching:1'/>
  <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/photo2.jpg' />
  </sources>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo2.jpg</body>
  <x xmlns='jabber:x:oob'><url>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo2.jpg</url></x>
</message>

<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='adding-photo3'>
  <attach-to id='sharing-files' xmlns='urn:xmpp:message-attaching:1'/>
  <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/photo3.jpg' />
  </sources>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo3.jpg</body>
  <x xmlns='jabber:x:oob'><url>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo3.jpg</url></x>
</message>

4.3 Compatibility with Stateless Inline Media Sharing

When sharing media, the sending entity may want to be compatible with Stateless Inline Media Sharing (XEP-0385) [1] as far as applicable. To do so, the Stateless Inline Media Sharing (XEP-0385) [1] <media-sharing/> element can be added inside an References (XEP-0372) [3] <reference xmlns='urn:xmpp:reference:0' type='data'> element in the same message that would also include the textual legacy fallback and Out-of-Band Data (XEP-0066) [12] x-oob reference.

Example 8. Sharing summit.jpg with juliet@shakespeare.lit in full compatibility mode
<message to='juliet@shakespeare.lit' from='romeo@montague.lit/resource' id='sharing-a-file'>
  <file-sharing xmlns='urn:xmpp:sfs:0' disposition='inline'>
    <file xmlns='urn:xmpp:file:metadata:0'>
      <media-type>image/jpeg</media-type>
      <name>summit.jpg</name>
      <size>3032449</size>
      <width>4096</width>
      <height>2160</height>
      <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>
  <reference xmlns='urn:xmpp:reference:0' type='data'>
    <media-sharing xmlns='urn:xmpp:sims:1'>
      <file xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
        <media-type>image/jpeg</media-type>
        <name>summit.jpg</name>
        <size>3032449</size>
        <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>
        <thumbnail xmlns='urn:xmpp:thumbs:1' uri='cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org' media-type='image/png' width='128' height='96'/>
      </file>
      <sources>
        <reference uri='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' type='data' xmlns='urn:xmpp:reference:0' />
      </sources>
    </media-sharing>
  </reference>
  <fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:sfs:0'><body/></fallback>
  <body>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>

5. Accessibility Considerations

Entities that support displaying moving images inline SHOULD have an option to turn this functionality off and display a still image instead.

Entities that support displaying files inline SHOULD have an option to turn this functionality off entirely.

6. Security Considerations

If a <hash/> using any supported algorithm is provided, the receiving client SHOULD verify that the <hash/> of the announced file matches the obained file before presenting it to the user. If no <hash/> is provided or the <hash/> 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 <hash/> is provided or the <hash/> elements provided use unsupported algorithms, receiving clients MUST ignore any sources that use unsecure protocols (e.g. HTTP without TLS).

For most methods of transferring a file proposed through the <sources/> 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.

The security considerations of File metadata element (XEP-0446) [2] apply.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [19].

8. XMPP Registrar Considerations

8.1 Protocol Namespaces

The XMPP Registrar [20] includes 'urn:xmpp:sfs:0' in its registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).

9. Acknowledgements

Thanks to the authors of Stateless Inline Media Sharing (XEP-0385) [1] which heavily inspired this XEP.

Thanks to Jérôme Poisson and others for their valuable feedback.


Appendices

Appendix A: Document Information

Series
XEP
Number
0447
Publisher
XMPP Standards Foundation
Status
Experimental
Type
Standards Track
Version
0.3.0
Last Updated
2023-06-24
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0001, XEP-0446
Supersedes
None
Superseded By
None
Short Name
sfs
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Marvin Wißfeld
Email
xmpp@larma.de
JabberID
jabber@larma.de

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0385: Stateless Inline Media Sharing (SIMS) <https://xmpp.org/extensions/xep-0385.html>.

2. XEP-0446: File metadata element <https://xmpp.org/extensions/xep-0446.html>.

3. XEP-0372: References <https://xmpp.org/extensions/xep-0372.html>.

4. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.

5. XEP-0369: Mediated Information eXchange (MIX) <https://xmpp.org/extensions/xep-0369.html>.

6. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

7. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.

8. XEP-0234: Jingle File Transfer <https://xmpp.org/extensions/xep-0234.html>.

9. XEP-0363: HTTP File Upload <https://xmpp.org/extensions/xep-0363.html>.

10. XEP-0300: Use of Cryptographic Hash Functions in XMPP <https://xmpp.org/extensions/xep-0300.html>.

11. XEP-0428: Fallback Indication <https://xmpp.org/extensions/xep-0428.html>.

12. XEP-0066: Out of Band Data <https://xmpp.org/extensions/xep-0066.html>.

13. XEP-0334: Message Processing Hints <https://xmpp.org/extensions/xep-0334.html>.

14. XEP-0103: URL Address Information <https://xmpp.org/extensions/xep-0103.html>.

15. XEP-0104: HTTP Scheme for URL Data <https://xmpp.org/extensions/xep-0104.html>.

16. XEP-0358: Publishing Available Jingle Sessions <https://xmpp.org/extensions/xep-0358.html>.

17. XEP-0367: Message Attaching <https://xmpp.org/extensions/xep-0367.html>.

18. XEP-0422: Message Fastening <https://xmpp.org/extensions/xep-0422.html>.

19. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

20. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.3.0 (2023-06-24)
    Describe how to use for multiple files, with body text, without any source in original message and compatibility with various current deployed protocols.
    lmw
  2. Version 0.2.0 (2022-08-03)
    Add disposition attribute to signal when inlining is desired.
    lmw
  3. Version 0.1.2 (2022-02-10)
    Replace the ProtoXEP reference with a reference to the published XEP.
    egp
  4. Version 0.1.1 (2020-12-30)
    Fixed typo in example.
    ps
  5. Version 0.1.0 (2020-11-24)
    Accepted by vote of Council on 2020-11-18.
    XEP Editor (jsc)
  6. Version 0.0.1 (2020-11-10)

    First draft.

    lmw

Appendix I: Bib(La)TeX Entry

@report{wißfeld2020sfs,
  title = {Stateless file sharing},
  author = {Wißfeld, Marvin},
  type = {XEP},
  number = {0447},
  version = {0.3.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0447.html},
  date = {2020-11-10/2023-06-24},
}

END