First draft.
This is a reiteration on &xep0385; with some significant changes:
To share a file, a user sends a message stanza including <file-sharing/> to the inteded recipient contact or group. The <file-sharing/> element includes a <file/> metadata element as described in &xep-file-metadata; as well as a <sources/> element. The <sources/> element provides one or multiple sources that the receiving client may use to obtain the file.
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.
The message MAY include a suitable fallback body. 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 &xep0066; x-oob reference is RECOMMENDED for compatibility.
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;.
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.
When the source is an <url-data/> 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 <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 &xep0358;, the receiving entity MAY obtain the file using the protocol described in &xep0358;. If a <hash/> is provided, the receiving entity MAY obtain the file by requesting it as described in &xep0234;.
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.
If the <media-type/> of the shared file is such that it can be displayed inline, the receiving entity MAY display the file inline. If no <media-type/> is provided or the <media-type/> indicates that the file can not be displayed inline, i.e. when the media type is application/octet-stream, the receiving entity SHOULD NOT display the file inline and instead offer to download it or save it on the users file system.
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.
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.
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 &xep0367;.
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;.
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 &xep-file-metadata; apply.
This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'urn:xmpp:sfs:0' in its registry of protocol namespaces (see &NAMESPACES;).
Thanks to the authors of &xep0385; which heavily inspired this XEP.