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. The <file-sharing/> element includes a <file/> metadata element as described in &xep0446; as well as a <sources/> element. The <sources/> element provides one or multiple sources that the receiving client may use to obtain the file.
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;.
+ 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 &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. @@ -154,9 +165,13 @@ 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. + 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:
+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.
@@ -183,6 +198,10 @@ ]]>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.
+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.