mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 15:18:51 -05:00
0091 to 0203
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@821 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
ac81b8c1a5
commit
0be5f868ba
26
xep-0060.xml
26
xep-0060.xml
@ -1,3 +1,17 @@
|
||||
PEP FEATURES
|
||||
|
||||
presence-subscribe (4.1)
|
||||
caps-filtering (4.2)
|
||||
auto-create (3)
|
||||
last-published (4.3.4 -- or config?)
|
||||
|
||||
one feature for each default access model?
|
||||
|
||||
OTHER FEATURES
|
||||
|
||||
subscribe-and-get (needed if last-published?)
|
||||
plus-private
|
||||
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
@ -1016,7 +1030,7 @@ And by opposing end them?
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The service MAY also send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &xep0091;) to indicate it is are sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)</p>
|
||||
<p>The service MAY also send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'urn:xmpp:delay' namespace (see &xep0203;) to indicate it is are sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)</p>
|
||||
<example caption='Service sends last published item'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
@ -1040,7 +1054,7 @@ And by opposing end them?
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
<x xmlns='jabber:x:delay' stamp='20031213T23:58:37'/>
|
||||
<delay xmlns='urn:xmpp:delay' stamp='2003-12-13T23:58:37Z'/>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>There are several reasons why the subscription request might fail:</p>
|
||||
@ -4550,6 +4564,14 @@ And by opposing end them?
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IM Account Integration' anchor='presence'>
|
||||
<p>Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see <cite>RFC 3921</cite>), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the account JID, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of buddies and shares presence information with those buddies, the virtual pubsub service can use the roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.</p>
|
||||
<section2 topic='Auto-Subscribe' anchor='auto-subscribe'>
|
||||
</section2>
|
||||
<section2 topic='Filtered Notifications' anchor='filtered-notifications'>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Feature Summary' anchor='features'>
|
||||
<p>This section summarizes the features described herein, specifies the appropriate requirements level for each feature (REQUIRED, RECOMMENDED, or OPTIONAL), and provides cross-references to the section of this document in which each feature is described.</p>
|
||||
<p>Note: The feature names are all of the form "http://jabber.org/protocol/pubsub#name", where "name" is the text specified in the first column below.</p>
|
||||
|
@ -77,7 +77,7 @@
|
||||
<priority>1</priority>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &xep0091; extension to indicate that the message was stored offline).</p>
|
||||
<p>The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &xep0203; extension to indicate that the message was stored offline).</p>
|
||||
<example caption='Recipient's Server Delivers Message'><![CDATA[
|
||||
<message from='romeo@montague.net/orchard' to='juliet@capulet.com'>
|
||||
<body>
|
||||
@ -85,9 +85,9 @@
|
||||
Being in night, all this is but a dream,
|
||||
Too flattering-sweet to be substantial.
|
||||
</body>
|
||||
<x from='capulet.com' stamp='20020910T23:08:25' xmlns='jabber:x:delay'>
|
||||
Offline Storage
|
||||
</x>
|
||||
<delay xmlns='urn:xmpp:delay'
|
||||
from='capulet.com'
|
||||
stamp='2002-09-10T23:08:25Z'>Offline Storage</delay>
|
||||
</message>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
@ -380,7 +380,7 @@
|
||||
|
||||
<section1 topic="Exchanging Stanzas" anchor='exchange'>
|
||||
<p>Alice MUST NOT send encrypted content within an offline ESession started by Bob. If Bob is conducting an offline ESession with Alice when she is online (e.g., if he is not subscribing to her presence), then if Alice wants to send a stanza to Bob, she MUST terminate the offline ESession and start a new online ESession first.</p>
|
||||
<p>For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &xep0091; element inserted by her server.</p>
|
||||
<p>For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &xep0203; element inserted by her server.</p>
|
||||
<example caption='Unencrypted Stanza'><![CDATA[
|
||||
<message from='bob@example.com/laptop'
|
||||
to='alice@example.org/pda'
|
||||
|
Loading…
Reference in New Issue
Block a user