diff --git a/xep-0060.xml b/xep-0060.xml index 9a02d401..937af9f1 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -49,6 +49,12 @@ &stpeter; &ralphm; + + 1.13.7 + 2017-08-24 + egp +

Fix examples using invalid XEP-0082 dates.

 + 1.13.6 2017-06-22 @@ -957,7 +963,7 @@ And by opposing end them? hamlet@denmark.lit - 2003-07-29T22:56Z + 2003-07-29T22:56:10Z Princely Musings (Atom) @@ -5519,7 +5525,7 @@ And by opposing end them? http://jabber.org/protocol/pubsub#subscribe_options ... - 2006-02-28T11:59Z + 2006-02-28T11:59:59Z ... @@ -5536,7 +5542,7 @@ And by opposing end them? http://jabber.org/protocol/pubsub#subscribe_options ... - 2006-03-31T23:59Z + 2006-03-31T23:59:59Z ... diff --git a/xep-0133.xml b/xep-0133.xml index 523b2adb..4fadc78b 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -21,6 +21,12 @@ admin &stpeter; + + 1.2 + 2017-07-15 + XEP Editor: ssw + Fix broken node value in example. + 1.1 2005-08-19 @@ -1613,7 +1619,7 @@ type='set' xml:lang='en'> diff --git a/xep-0234.xml b/xep-0234.xml index 92abb00b..301aceaf 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -24,6 +24,12 @@ NOT_YET_ASSIGNED &stpeter; &lance; + + 0.18.3 + 2017-08-24 + ps +

Make use of <hash-used/> from XEP-0300.

 + 0.18.2 2017-08-23 @@ -365,7 +371,12 @@ hash 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. - REQUIRED when offering a file, otherwise OPTIONAL + See <hash-used/> + + + hash-used + 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. + Either a <hash/> or a <hash-used/> element MUST be included when offering a file. media-type @@ -796,7 +807,7 @@ a=file-range:1024-*]]>

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.

This can be done in the session-initiate message if the File Sender already knows the checksum, as shown above in Example 3.

-

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;.

+

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;.

+ 0.5.2 + 2017-08-21 + ps +

Add hash-used element

 + 0.5.1 2017-03-17 @@ -93,6 +99,8 @@

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:

2AfMGH8O7UNPTvUVAM9aK13mpCY= 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=]]> +

In certain scenarios it makes sense to communicate the hash algorithm that is used prior to the calculation of the hash value.

+ ]]>

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.

@@ -393,13 +401,21 @@ + + + + + + + + ]]>

Thanks to Dave Cridland, Waqas Hussain, Glenn Maynard, Remko - Tronçon, and Christian Schudt for their input.

+ Tronçon, Paul Schaub and Christian Schudt for their input.

 diff --git a/xep-0357.xml b/xep-0357.xml index 2303f15e..2f414c3d 100644 --- a/xep-0357.xml +++ b/xep-0357.xml @@ -23,12 +23,17 @@ push - - Lance - Stout - lancestout@gmail.com - lance@lance.im - + &kev; + &lance; + + 0.3 + 2017-08-24 + XEP Editor (jwi) +
    +
  • Use server JID as 'from' address for notifications (hw).
    • +
  • Added Kevin Smith as author (ls).
    • +
+ 0.2.1 2016-02-16 @@ -189,8 +194,8 @@

Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user.

-

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.

-

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 Enabling Notifications).

+

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.

+

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 Enabling Notifications).

 @@ -324,7 +329,7 @@

Other elements MAY be included if relevant for the notification.

@@ -349,7 +354,7 @@