Add XEP proposal for a generic file metadata element

This commit is contained in:
Marvin W 2020-11-10 20:49:42 +01:00
parent f352fd999b
commit c7e82167f0
No known key found for this signature in database
GPG Key ID: 072E9235DB996F2A
2 changed files with 154 additions and 0 deletions

inbox/file-metadata.xml Normal file
View File

@ -0,0 +1,146 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<title>File metadata element</title>
<abstract>This specification defines a generic file metadata element to be used in other specifications.</abstract>
<type>Standards Track</type>
<spec>XMPP Core</spec>
<remark><p>First draft.</p></remark>
<section1 topic='Introduction' anchor='intro'>
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.
<section1 topic='Element format' anchor='format'>
<file xmlns='urn:xmpp:file:metadata:0'>
<hash xmlns='urn:xmpp:hashes:2'
<p>The child elements of the &lt;file/&gt; element are as follows:</p>
<table caption='File Description Elements'>
<th>Element Name</th>
<td>Timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;).</td>
<td>Horizontal and vertical dimensions of image or video files, in pixels.</td>
<td>A human readable description of the file. Multiple <tt>&lt;desc/&gt;</tt> elements MAY be included if different xml:lang values are specified.</td>
<td><tt>Picture of 24th XSF Summit</tt></td>
<td>A hash of the file content, using the <tt>&lt;hash/&gt;</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>
<td>Length of an audio or video file, in milliseconds.</td>
<td>The media type of the file content, which SHOULD be a valid MIME-TYPE as registered with &IANA; (specifically, as listed at &lt;<link url=''></link>&gt;). If not specified, the content is assumed to be "application/octet-stream".</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>The length of the file's content, in bytes.</td>
<td>A thumbnail element of the file, using the &lt;thumbnail/&gt; 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>
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.
<section1 topic='Security Considerations' anchor='security'>
Caution needs to be exercised when using the <tt>&lt;name/&gt;</tt> of the metadata
to control any interaction with a file system. For example, a malicious
user could request a file with <tt>&lt;name&gt;/etc/passwd&lt;/name&gt;</tt> or
include file system specific control patterns such as
<tt>&lt;name&gt;../../private.txt&lt;/name&gt;</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>&lt;name/&gt;</tt> before
using that value in any file system calls.
It is RECOMMENDED for implementations to use the strongest hashing
algorithm available to both parties. See &xep0300; for further discussion.
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>The &REGISTRAR; includes 'urn:xmpp:file:metadata:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to the authors of &xep0234; which heavily inspired this XEP.</p>

View File

@ -1115,6 +1115,14 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
" >
<!ENTITY larma "
<!-- XMPP Extension Protocols -->