<examplecaption='Result from PASS Service'><![CDATA[
<iqid='pass1'type='result'from='pass.jabber.org'>
<queryxmlns='jabber:iq:pass'>
<serverport='43253'>1.2.3.4</server>
</query>
</iq>
]]></example>
]]></example>
<p>At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.</p>
<p>The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an <expire/> value (in seconds). If the service is not configured with an expire value, it will not timeout the connection, and will start listening on the port again after one of the two sides disconnects.</p>
<tablecaption='Error Codes'>
@ -125,7 +125,7 @@
@@ -125,7 +125,7 @@
<proxyport='43523'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='IQ result to accept connection'><![CDATA[
<iqtype='result'
id='pass2'
@ -133,7 +133,7 @@
@@ -133,7 +133,7 @@
to='pass.jabber.org'>
<queryxmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<p>The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.</p>
<p>Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.</p>
</section1>
@ -152,7 +152,7 @@
@@ -152,7 +152,7 @@
<proxyport='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Acknowledgement of expiration'><![CDATA[
<iqtype='result'
id='pass3'
@ -160,7 +160,7 @@
@@ -160,7 +160,7 @@
to='pass.jabber.org'>
<queryxmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
</section2>
<section2topic='oneshot'>
<p>This tells the server to listen once, and then close the port. Even if the <expire/> has not been met, the <oneshot/> overrides that and shuts down the listening port. When this happens the server notifies the client with the following packet:</p>
@ -175,7 +175,7 @@
@@ -175,7 +175,7 @@
<proxyport='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Client acknowledges closing of oneshot port'><![CDATA[
<iqtype='result'
id='pass4'
@ -183,7 +183,7 @@
@@ -183,7 +183,7 @@
to='pass.jabber.org'>
<queryxmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
</section2>
<section2topic='close'>
<p>This tells the server to explicitly shut down a listening port. Useful for when the client shuts down and can tell the PASS service to recycle the port. The server sends back:</p>
@ -197,7 +197,7 @@
@@ -197,7 +197,7 @@
<proxyport='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Server acknowledges port closing request'><![CDATA[
<iqtype='result'
id='pass5'
@ -205,7 +205,7 @@
@@ -205,7 +205,7 @@
from='pass.jabber.org'>
<queryxmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<tablecaption='Error Codes'>
<tr>
<th>Code</th>
@ -246,7 +246,7 @@
@@ -246,7 +246,7 @@
from='you@jabber.org/resource'>
<queryxmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<p>The other client SHOULD send back:</p>
<example><![CDATA[
<iqtype='result'
@ -257,7 +257,7 @@
@@ -257,7 +257,7 @@
<client>4.3.2.1</client>
</query>
</iq>
]]></example>
]]></example>
<p>Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the <client/> information upon a connection.</p>
<p>The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included either directly as a first-level child of a &MESSAGE; stanza or as a second-level child of an &IQ; stanza (where the first-level child is an element qualified by a "wrapper" namespace); see also the restrictions enumerated below.</p>
<p>The OPTIONAL <title/> and <instructions/> elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the <instructions/> element MAY be included.</p>
<p>Each of these elements MUST contain one or more <field/> children. The <reported/> element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the <field/> elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a <value/> element. Each <item/> element defines one item in the result set, and MUST contain each field specified in the <reported/> element (although the XML character data of the <value/> element MAY be null).</p>
</section2>
</section1>
@ -321,7 +321,7 @@
@@ -321,7 +321,7 @@
node='create'
action='execute'/>
</iq>
]]></example>
]]></example>
<p>The hosting service then returns a data form to the user:</p>
<p>Now that the user has created this search bot, let us suppose that one of the friends he has invited decides to try it out by sending a search request:</p>
<examplecaption="Service Discovery information response"><![CDATA[
<iqtype='result'
from='juliet@capulet.com/balcony'
@ -604,7 +604,7 @@
@@ -604,7 +604,7 @@
...
</query>
</iq>
]]></example>
]]></example>
<p>If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.</p>
<p>If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:</p>
<examplecaption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[
<p>If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":</p>
<p>An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
<p>The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this document will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.</p>
<p>The target entity MUST return either an IQ-result or an IQ-error. When returning an IQ-result, the target entity sends an &IQ; stanza of type='result' containing a &QUERY; element with a REQUIRED 'seconds' attribute and OPTIONAL XML character data.</p>
<p>The requesting entity interprets the IQ-result based on the responding entity's JID type in order to determine the meaning of the information. Specifically, the information means something different depending on the identity of the responding entity:</p>
<ol>
<li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li>
@ -114,7 +114,7 @@
@@ -114,7 +114,7 @@
type='get'>
<queryxmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<p>As specified in &xmppcore; and &xmppim;, an IQ stanza of type "get" sent to a bare JID &LOCALBARE; is handled by the user's server on the user's behalf, not delivered to one or more connected or available resources.</p>
<p>If the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP-IM</cite>), the user's server MUST NOT return last activity information but instead MUST return a &forbidden; error in response to the last activity request.</p>
<examplecaption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
<p>If the requesting entity is authorized to view the user's presence information, the server shall return information about the last presence activity recorded by the server for that user.</p>
<examplecaption='Last Activity Response by Server'><![CDATA[
<p>In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence stanza of type='unavailable' whose <status/> element contained the text "Heading Home".</p>
<p>If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty <query/> element whose 'seconds' attribute is set to a value of '0'.</p>
</section1>
@ -148,7 +148,7 @@
@@ -148,7 +148,7 @@
type='get'>
<queryxmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<p>In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user.</p>
<p>In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP IM</cite>), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a &forbidden; error in response to the last activity request.</p>
<examplecaption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
<p>If the user's server delivers the IQ-get to one of the user's available resources, the user's client MAY respond with the idle time of the user (i.e., the last time that a human user interacted with the client application).</p>
<examplecaption='Last Activity Response by Client'><![CDATA[
<iqfrom='juliet@capulet.com/balcony'
@ -169,7 +169,7 @@
@@ -169,7 +169,7 @@
type='result'>
<queryxmlns='jabber:iq:last'seconds='123'/>
</iq>
]]></example>
]]></example>
<p>In the foregoing example, the user has been idle for about two minutes.</p>
<p>Support for this functionality is OPTIONAL. A client that does not support the protocol, or that does not wish to divulge this information, MUST return a &unavailable; error.</p>
<p>If there is no available resource matching the &LOCALBARE; in the 'to' attribute of the request, the server MUST follow the rules in <cite>XMPP IM</cite> in order to determine what error stanza to return.</p>
</section1>
<section1topic='Server and Component Query'anchor='server'>
@ -193,7 +193,7 @@
@@ -193,7 +193,7 @@
type='get'>
<queryxmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<examplecaption='Last Activity Response from Server or Service'><![CDATA[
<iqfrom='capulet.com'
id='last3'
@ -201,7 +201,7 @@
@@ -201,7 +201,7 @@
type='result'>
<queryxmlns='jabber:iq:last'seconds='123456'/>
</iq>
]]></example>
]]></example>
<p>In this example, the server has been running for a little more than 34 hours.</p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
<p>If the server supports this protocol, it MUST return a <feature/> element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
</section2>
<section2topic='Requesting Number of Messages'anchor='request-number'>
<p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p>
<examplecaption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
<iqtype='result'to='romeo@montague.net/orchard'>
@ -164,7 +164,7 @@
@@ -164,7 +164,7 @@
</x>
</query>
</iq>
]]></example>
]]></example>
<p>Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.</p>
<p>The server now MUST return headers for all of the user's offline messages. So that the user may determine whether to view a full message, the header information provided MUST include the full Jabber ID of the sender (encoded in the 'name' attribute) and a unique identifier for the message within the user's "inbox" (encoded in the 'node' attribute), so that the user may appropriately manage (view or remove) the message.</p>
<p>If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. If there are no offline messages for this user, the server MUST return an empty query as defined in XEP-0030. (For information about the syntax of error conditions, refer to &xep0086;.)</p>
<p>The syntax and semantics of the attributes are as follows:</p>
<ul>
@ -220,7 +220,7 @@
@@ -220,7 +220,7 @@
node='2003-02-27T22:52:37.225Z'/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p>
<p>In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &xep0091; information in the message.</p>
</section2>
<section2topic='Removing Specific Messages'anchor='remove-specific'>
@ -246,11 +246,11 @@
@@ -246,11 +246,11 @@
node='2003-02-27T22:52:37.225Z'/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove the messages and inform the user:</p>
<examplecaption='Server Informs User of Removal'><![CDATA[
<section2topic='Retrieving All Messages'anchor='retrieve-all'>
<p>The user retrieves all message by sending the "fetch" command:</p>
@ -260,7 +260,7 @@
@@ -260,7 +260,7 @@
<fetch/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST retrieve all messages and inform the user:</p>
<examplecaption='Server Sends All Messages and Informs User of Successful Fetch'><![CDATA[
<p>A client MAY retrieve all messages without first requesting message headers. In this case, the server MUST return all of the user's offline messages and also MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. That is, the semantics here are the same as for requesting message headers.</p>
</section2>
<section2topic='Removing All Messages'anchor='remove-all'>
@ -282,11 +282,11 @@
@@ -282,11 +282,11 @@
<purge/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove all messages and inform the user:</p>
<examplecaption='Server Informs User of Successful Purge'><![CDATA[
@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc.
@@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc.
<doc>XEP-0013</doc>
</type>
</category>
]]></code>
]]></code>
</section2>
<section2topic='Well-Known Service Discovery Nodes'anchor='registrar-disco-nodes'>
<p>The XMPP Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.</p>
@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc.
@@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc.
type='text-single'
label='N/A'/>
</form_type>
]]></code>
]]></code>
</section2>
</section1>
<section1topic='XML Schema'anchor='schema'>
@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
@@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
<p>In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.</p>
<p>If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:</p>
<examplecaption='Client attempts to retrieve non-existent list'><![CDATA[
@ -268,7 +268,7 @@
@@ -268,7 +268,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
<p>The user is allowed to retrieve only one list at a time. If the user attempts to retrieve more than one list in the same request, the server MUST return a <bad request/> stanza error to the user:</p>
<examplecaption='Client attempts to retrieve more than one list'><![CDATA[
<section2topic="Managing Active Lists"anchor="protocol-active">
<p>In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <active/> child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@ -292,11 +292,11 @@
@@ -292,11 +292,11 @@
<activename='special'/>
</query>
</iq>
]]></example>
]]></example>
<p>The server MUST activate and apply the requested list before sending the result back to the client.</p>
<examplecaption='Server acknowledges success of active list change'><![CDATA[
<p>If the user attempts to set an active list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:</p>
<examplecaption='Client attempts to set a non-existent list as active'><![CDATA[
<section2topic="Managing the Default List"anchor="protocol-default">
<p>In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <default/> child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@ -329,10 +329,10 @@
@@ -329,10 +329,10 @@
<defaultname='special'/>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Server acknowledges success of default list change'><![CDATA[
<p>If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a <conflict/> stanza error to the sending resource:</p>
<examplecaption='Client attempts to change the default list but that list is in use by another resource'><![CDATA[
<p>If the user attempts to set a default list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:</p>
<examplecaption='Client attempts to set a non-existent list as default'><![CDATA[
<p>In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty <default/> element with no 'name' attribute.</p>
<examplecaption='Client declines the use of the default list'><![CDATA[
<p>If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a <conflict/> error to the sending resource:</p>
<examplecaption='Client attempts to decline a default list but that list is in use by another resource'><![CDATA[
<section2topic="Editing a Privacy List"anchor="protocol-edit">
<p>In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The <list/> element MUST contain one or more <item/> elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").</p>
@ -399,10 +399,10 @@
@@ -399,10 +399,10 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Server acknowledges success of list edit'><![CDATA[
<p>Note: The value of the 'order' attribute for any given item is not fixed. Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.</p>
<p>The server MUST now send a "privacy list push" to all connected resources:</p>
<examplecaption='Privacy list push on list edit'><![CDATA[
@ -417,7 +417,7 @@
@@ -417,7 +417,7 @@
<listname='public'/>
</query>
</iq>
]]></example>
]]></example>
<p>In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:</p>
<examplecaption='Acknowledging receipt of privacy list pushes'><![CDATA[
<iqfrom='romeo@example.net/orchard'
@ -427,7 +427,7 @@
@@ -427,7 +427,7 @@
<iqfrom='romeo@example.net/home'
type='result'
id='push2'/>
]]></example>
]]></example>
</section2>
<section2topic="Adding a New Privacy List"anchor="protocol-add">
<p>The same protocol used to edit an existing list is used to create a new list. If the list name matches that of an existing list, the request to add a new list will overwrite the old one. As with list edits, the server MUST also send a "privacy list push" to all connected resources.</p>
@ -440,10 +440,10 @@
@@ -440,10 +440,10 @@
<listname='private'/>
</query>
</iq>
]]></example>
]]></example>
<examplecaption='Server acknowledges success of list removal'><![CDATA[
<p>If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a <conflict/> stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it. If the user attempts to remove a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a <bad request/> stanza error to the user.</p>
<p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.</p>
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.</p>
<examplecaption='User blocks based on roster group'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.</p>
<examplecaption='User blocks based on subscription type'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.</p>
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</p>
<p>Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.</p>
</section2>
@ -584,7 +584,7 @@
@@ -584,7 +584,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.</p>
<examplecaption='User blocks based on roster group'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.</p>
<examplecaption='User blocks based on subscription type'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.</p>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
<p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
</section2>
@ -645,7 +645,7 @@
@@ -645,7 +645,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.</p>
<examplecaption='User blocks based on roster group'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.</p>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.</p>
</section2>
<section2topic="Blocking All Communication"anchor="protocol-all">
@ -703,7 +703,7 @@
@@ -703,7 +703,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.</p>
<examplecaption='User blocks based on roster group'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.</p>
<examplecaption='User blocks based on subscription type'><![CDATA[
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.</p>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.</p>
</section2>
<section2topic="Blocked Entity Attempts to Communicate with User"anchor="protocol-error">
@ -757,7 +757,7 @@
@@ -757,7 +757,7 @@
id='probing1'>
<queryxmlns='jabber:iq:version'/>
</iq>
]]></example>
]]></example>
<examplecaption='Server returns error to blocked entity'><![CDATA[
<iqtype='error'
from='romeo@example.net'
@ -769,7 +769,7 @@
@@ -769,7 +769,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
<p>If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a ¬acceptable; error:</p>
<examplecaption='Error: contact is blocked'><![CDATA[
<p>Note: If the responding entity does not want to reveal presence to the initiating entity for whatever reason then the responding entity's client SHOULD return a &unavailable; error (or return no response or error whatsoever if the offer was wrapped in a &MESSAGE; stanza) - see <linkurl='#security'>Security Considerations</link>.</p>
<p>If the responding entity does not support <strong>Feature Negotiation</strong> or does not support the specified FORM_TYPE, it SHOULD also return a &unavailable; error:</p>
<examplecaption="Responding entity does not support feature negotiation"><![CDATA[
<p>If the responding entity does not support one or more of the features, it SHOULD return a &feature; error, and SHOULD specify the feature(s) not implemented in the XMPP <text/> element.</p>
<examplecaption="Responding entity does not support a feature"><![CDATA[
<p>If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a ¬acceptable; error, and SHOULD specify the relevant feature(s) in the XMPP <text/> element.</p>
<examplecaption="Responding entity supports no options"><![CDATA[
<section2topic="Querying for Negotiable Features"anchor='protocol-query'>
<p>If at least one feature offered by an entity is subject to <strong>Feature Negotiation</strong>, the entity's response to a service discovery information request MUST include <feature var='http://jabber.org/protocol/feature-neg'/> as one of the features.</p>
@ -314,7 +314,7 @@
@@ -314,7 +314,7 @@
</xs:element>
</xs:schema>
]]></code>
]]></code>
</section1>
<section1topic='Author Note'anchor='authornote'>
<p>Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining authors are thankful for Peter's work on this specification.</p>
<p>Here we see the sender wants to be notified if the message is stored offline (by the server), notified when the message is delivered (to the client), and notified if the recipient begins replying to the message. In this case, the sender will potentially receive three events based on this request. The first if the recipient is offline and the message is stored on the server, the second when the recipient becomes available and the message is delivered, and the third if the recipient begins composing a reply to the message.</p>
<p>Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.</p>
</section2>
@ -137,7 +137,7 @@
@@ -137,7 +137,7 @@
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p>
<ul>
<li>The element must contain only a jabber:x:event extension. Standard message elements such as <subject/>, <body/>, MUST NOT be included.</li>
@ -160,7 +160,7 @@
@@ -160,7 +160,7 @@
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<examplecaption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[
<message
from='romeo@montague.net'
@ -169,7 +169,7 @@
@@ -169,7 +169,7 @@
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<p>The lack of an <composing/> tag (and any other event tag) signifies that the composing event, indicated previously by the id value, has been cancelled. In this example, the composing event being cancelled is that event that was previously raised with the id of message22. After cancelling a composing event, a new one may be raised, following the same rules as before, when the typing of the reply is resumed.</p>
<p>Romeo temporarily loses his wireless connection in the Capulet's orchard and therefore his message is stored offline by the montague.net server, which generates the offline event and sends that notification to Juliet.</p>
<examplecaption='Receiving the offline event'><
Emmanuel Gil Peyrot
5 years ago
committed by