-
Notifications
You must be signed in to change notification settings - Fork 116
/
xep-0446.xml
163 lines (163 loc) · 6.7 KB
/
xep-0446.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
<?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.2.0</version>
<date>2022-07-17</date>
<initials>lmw</initials>
<remark>Use height/width instead of dimensions</remark>
</revision>
<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>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>height</td>
<td>Vertical dimensions of image or video files, in pixels.</td>
<td><tt>1920</tt></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>
<tr>
<td>width</td>
<td>Horizontal dimensions of image or video files, in pixels.</td>
<td><tt>1080</tt></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>