moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

errata 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3468 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-09-29 18:36:11 +00:00
parent 26f625bae5
commit 9ebd717e7a
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
xep-0060.xml
View File

@ -59,6 +59,7 @@
<li>Removed delete-any and delete-node features.</li>
<li>Added missing delete-items feature.</li>
<li>Removed replyto and replyroom config options.</li>
<li>Removed multiple node discovery since it depended on the deprecated Service Discovery Publishing feature.</li>
<li>Defined "room" value for itemreply config option.</li>
<li>Added optional 'publisher' attribute to &lt;item/&gt; element.</li>
<li>Added optional &lt;redirect/&gt; child to &lt;delete/&gt; element.</li>
@ -3396,7 +3397,7 @@ And by opposing end them?
from='hamlet@denmark.lit/elsinore'
to='pubsub.shakespeare.lit'
id='config1'>
<error type='cancel'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<nodeid-required xmlns='http://jabber.org/protocol/pubsub#errors'/>
</error>
@ -4596,7 +4597,7 @@ And by opposing end them?
</section2>
<section2 topic='Filtered Notifications' anchor='filtered-notifications'>
<p>A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including <cite>XEP-0115</cite> information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences.</p>
<p>In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in XEP-0080, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.</note></p>
<p>In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in <cite>XEP-0080</cite>, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation, where the NodeID is the same as the geolocation namespace 'http://jabber.org/protocol/geoloc' (in this case there is a one-to-one correspondence between the namespace name and the NodeID).</note></p>
<ul>
<li>http://jabber.org/protocol/geoloc+notify</li>
<li>http://jabber.org/protocol/tune+notify</li>
@ -5483,7 +5484,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<section2 topic='Presence Leaks' anchor='security-presence'>
<p>In the context of instant messaging systems it is possible for the act of publishing an item to reveal the node owner or item publisher's network availability. However, this risk is mitigated by the following factors:</p>
<ol>
<li>A node does not necessarily reveal the existing of the publishing entity.</li>
<li>A node does not necessarily reveal the existence of the publishing entity.</li>
<li>XMPP PubSub systems are not necessarily tied to instant messaging systems.</li>
<li>Even in the context of IM systems, a node provides information distinct from network availability (e.g., user tunes).</li>
<li>Even then, the actual publisher might not be an IM user (e.g., an automated calendaring or geolocation system).</li>
@ -6019,9 +6020,6 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<option label='Messages of type headline'>
<value>headline</value>
</option>
<option label='Anyone may publish'>
<value>open</value>
</option>
</field>
<field var='pubsub#notify_config'
type='boolean'