<remark><p>Make use of <hash-used/> from XEP-0300.</p></remark>
</revision>
<revision>
<version>0.18.2</version>
<date>2017-08-23</date>
@ -365,7 +371,12 @@
<tr>
<td>hash</td>
<td>A hash of the file content, using the <hash/> element defined in &xep0300; and qualifed by the 'urn:xmpp:hashes:2' namespace. Multiple hashes MAY be included for hash agility.</td>
<td>REQUIRED when offering a file, otherwise OPTIONAL</td>
<td>See <hash-used/></td>
</tr>
<tr>
<td>hash-used</td>
<td>Alternatively to a <hash/> element, the initiator can also include a <hash-used/> element. This avoids the need to read the file twice to calculate the hash.</td>
<td>Either a <hash/> or a <hash-used/> element MUST be included when offering a file.</td>
</tr>
<tr>
<td>media-type</td>
@ -796,7 +807,7 @@ a=file-range:1024-*]]></code>
<section2topic='Checksum'anchor='hash'>
<p>At any time during the lifetime of the file transfer session, the File Sender can communicate the checksum of the file to the File Receiver.</p>
<p>This can be done in the session-initiate message if the File Sender already knows the checksum, as shown above in Example 3.</p>
<p>After the session-initiate message, this can also be done by sending a session-info message containing a <checksum/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:5' namespace. The <checksum/> element SHOULD contain 'creator' and 'name' attributes sufficient to identitfy the content the checksum belongs to. Additionally, the <checksum/> element MUST contain a <file/> element which MUST contain at least one <hash/> element qualified by the 'urn:xmpp:hashes:2' namespace. Each <hash/> element contains a checksum of the file data produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;.</p>
<p>After the session-initiate message, this can also be done by sending a session-info message containing a <checksum/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:5' namespace. In such a case however, the session-initiate message MUST contain a <hash-used/> element. The <checksum/> element SHOULD contain 'creator' and 'name' attributes sufficient to identitfy the content the checksum belongs to. Additionally, the <checksum/> element MUST contain a <file/> element which MUST contain at least one <hash/> or <hash-used/> element qualified by the 'urn:xmpp:hashes:2' namespace. Each <hash/> element contains a checksum of the file data produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;.</p>
<examplecaption="Initiator sends checksum in session-info"><![CDATA[
<p>An XMPP protocol can include more than one instance of the <hash/> element, as long as each one has a different value for the 'algo' attribute:</p>
<li>Use server JID as 'from' address for notifications (hw).</li>
<li>Added Kevin Smith as author (ls).</li>
</ul></remark>
</revision>
<revision>
<version>0.2.1</version>
<date>2016-02-16</date>
@ -189,8 +194,8 @@
</section2>
<section2topic='Business Rules'>
<p>Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user.</p>
<p>In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the user's bare JID) to publish to the node to trigger notifications.</p>
<p>Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from bare JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see <linkurl='#publish-options'>Enabling Notifications</link>).</p>
<p>In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the server JID and the user's bare JID) to publish to the node to trigger notifications.</p>
<p>Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from server JIDs and bare user JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see <linkurl='#publish-options'>Enabling Notifications</link>).</p>
</section2>
</section1>
@ -324,7 +329,7 @@
<p>Other elements MAY be included if relevant for the notification.</p>
<examplecaption='Server publishes a push notification'><![CDATA[
<iqtype='set'
from='user@example.com'
from='example.com'
to='push-5.client.example'
id='n12'>
<pubsubxmlns='http://jabber.org/protocol/pubsub'>
@ -349,7 +354,7 @@
<examplecaption='Server publishes a push notification with provided publish options'><![CDATA[