mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 07:38:52 -05:00
Merge branches 'feature/xep-0060', 'feature/xep-0133', 'feature/xep-0234,xep-0300' and 'feature/xep-0357'
This commit is contained in:
Jonas Wielicki
commit
ee3095e24b
14
xep-0060.xml
14
xep-0060.xml
@ -49,6 +49,12 @@
|
||||
&stpeter;
|
||||
&ralphm;
|
||||
|
||||
<revision>
|
||||
<version>1.13.7</version>
|
||||
<date>2017-08-24</date>
|
||||
<initials>egp</initials>
|
||||
<remark><p>Fix examples using invalid XEP-0082 dates.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.13.6</version>
|
||||
<date>2017-06-22</date>
|
||||
@ -957,7 +963,7 @@ And by opposing end them?
|
||||
<value>hamlet@denmark.lit</value>
|
||||
</field>
|
||||
<field var='pubsub#creation_date' label='Creation date' type='text-single'>
|
||||
<value>2003-07-29T22:56Z</value>
|
||||
<value>2003-07-29T22:56:10Z</value>
|
||||
</field>
|
||||
<field var='pubsub#title' label='A short name for the node' type='text-single'>
|
||||
<value>Princely Musings (Atom)</value>
|
||||
@ -5519,7 +5525,7 @@ And by opposing end them?
|
||||
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>
|
||||
</field>
|
||||
...
|
||||
<field var='pubsub#expire'><value>2006-02-28T11:59Z</value></field>
|
||||
<field var='pubsub#expire'><value>2006-02-28T11:59:59Z</value></field>
|
||||
...
|
||||
</x>
|
||||
</options>
|
||||
@ -5536,7 +5542,7 @@ And by opposing end them?
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit/barracks'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<subscription
|
||||
expiry='2006-02-28T23:59Z'
|
||||
expiry='2006-02-28T23:59:59Z'
|
||||
jid='francisco@denmark.lit'
|
||||
node='princely_musings'
|
||||
subid='ba49252aaa4f5d320c24d3766f0bdcade78c78d3'
|
||||
@ -5585,7 +5591,7 @@ And by opposing end them?
|
||||
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>
|
||||
</field>
|
||||
...
|
||||
<field var='pubsub#expire'><value>2006-03-31T23:59Z</value></field>
|
||||
<field var='pubsub#expire'><value>2006-03-31T23:59:59Z</value></field>
|
||||
...
|
||||
</x>
|
||||
</options>
|
||||
|
||||
@ -21,6 +21,12 @@
|
||||
<supersededby/>
|
||||
<shortname>admin</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.2</version>
|
||||
<date>2017-07-15</date>
|
||||
<initials>XEP Editor: ssw</initials>
|
||||
<remark>Fix broken node value in example.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.1</version>
|
||||
<date>2005-08-19</date>
|
||||
@ -1613,7 +1619,7 @@
|
||||
type='set'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='http://jabber.org/protocol/admin#edit-whitelist'
|
||||
node='http://jabber.org/protocol/admin#get-online-users-list'
|
||||
sessionid='get-online-users-list:20040408T0337Z'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field type='hidden' var='FORM_TYPE'>
|
||||
|
||||
15
xep-0234.xml
15
xep-0234.xml
@ -24,6 +24,12 @@
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
&stpeter;
|
||||
&lance;
|
||||
<revision>
|
||||
<version>0.18.3</version>
|
||||
<date>2017-08-24</date>
|
||||
<initials>ps</initials>
|
||||
<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>
|
||||
<section2 topic='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>
|
||||
<example caption="Initiator sends checksum in session-info"><![CDATA[
|
||||
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
id='kqh401b5'
|
||||
|
||||
18
xep-0300.xml
18
xep-0300.xml
@ -24,6 +24,12 @@
|
||||
&mwild;
|
||||
&ksmith;
|
||||
&tobias;
|
||||
<revision>
|
||||
<version>0.5.2</version>
|
||||
<date>2017-08-21</date>
|
||||
<initials>ps</initials>
|
||||
<remark><p>Add hash-used element</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.5.1</version>
|
||||
<date>2017-03-17</date>
|
||||
@ -93,6 +99,8 @@
|
||||
<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>
|
||||
<code><![CDATA[<hash xmlns='urn:xmpp:hashes:2' algo='sha-1'>2AfMGH8O7UNPTvUVAM9aK13mpCY=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</hash>]]></code>
|
||||
<p>In certain scenarios it makes sense to communicate the hash algorithm that is used prior to the calculation of the hash value.</p>
|
||||
<code><![CDATA[<hash-used xmlns='urn:xmpp:hashes:2' algo='sha-256'/>]]></code>
|
||||
<p>The value of the 'algo' attribute MUST be one of the values from the &ianahashes; maintained by &IANA;, or one of the values
|
||||
defined in the following table.</p>
|
||||
<table caption='Additional Hash Function Textual Names'>
|
||||
@ -393,13 +401,21 @@
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='hash-used'>
|
||||
<xs:complexType>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='algo' type='xs:NCName' use='required'/>
|
||||
</xs:extension>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Dave Cridland, Waqas Hussain, Glenn Maynard, Remko
|
||||
Tronçon, and Christian Schudt for their input.</p>
|
||||
Tronçon, Paul Schaub and Christian Schudt for their input.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
||||
25
xep-0357.xml
25
xep-0357.xml
@ -23,12 +23,17 @@
|
||||
<supersedes />
|
||||
<supersededby/>
|
||||
<shortname>push</shortname>
|
||||
<author>
|
||||
<firstname>Lance</firstname>
|
||||
<surname>Stout</surname>
|
||||
<email>lancestout@gmail.com</email>
|
||||
<jid>lance@lance.im</jid>
|
||||
</author>
|
||||
&kev;
|
||||
&lance;
|
||||
<revision>
|
||||
<version>0.3</version>
|
||||
<date>2017-08-24</date>
|
||||
<initials>XEP Editor (jwi)</initials>
|
||||
<remark><ul>
|
||||
<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>
|
||||
<section2 topic='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 <link url='#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 <link url='#publish-options'>Enabling Notifications</link>).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
@ -324,7 +329,7 @@
|
||||
<p>Other elements MAY be included if relevant for the notification.</p>
|
||||
<example caption='Server publishes a push notification'><![CDATA[
|
||||
<iq type='set'
|
||||
from='user@example.com'
|
||||
from='example.com'
|
||||
to='push-5.client.example'
|
||||
id='n12'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
@ -349,7 +354,7 @@
|
||||
|
||||
<example caption='Server publishes a push notification with provided publish options'><![CDATA[
|
||||
<iq type='set'
|
||||
from='user@example.com'
|
||||
from='example.com'
|
||||
to='push-5.client.example'
|
||||
id='n12'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user