moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 07:08:51 -05:00
Code Issues Releases Wiki Activity

Remove spaces at the end of CDATA blocks in all XEPs.

Browse Source 
sed -i 's/^\s\+]]>/]]>/g' xep-*.xml
This commit is contained in:
Emmanuel Gil Peyrot 2017-02-14 22:08:49 +00:00 committed by Sam Whited
parent fe9d3969fd
commit 7a64b7b1ed
258 changed files with 3563 additions and 3560 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0001.xml
View File

@ -846,6 +846,6 @@ THE SOFTWARE.
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

30
xep-0003.xml
View File

@ -90,14 +90,14 @@
<expire>600</expire> <expire>600</expire>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Result from PASS Service'><![CDATA[ <example caption='Result from PASS Service'><![CDATA[
<iq id='pass1' type='result' from='pass.jabber.org'> <iq id='pass1' type='result' from='pass.jabber.org'>
<query xmlns='jabber:iq:pass'> <query xmlns='jabber:iq:pass'>
<server port='43253'>1.2.3.4</server> <server port='43253'>1.2.3.4</server>
</query> </query>
</iq> </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>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 &lt;expire/&gt; 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> <p>The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an &lt;expire/&gt; 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>
<table caption='Error Codes'> <table caption='Error Codes'>
@ -125,7 +125,7 @@
<proxy port='43523'>1.2.3.4</proxy> <proxy port='43523'>1.2.3.4</proxy>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='IQ result to accept connection'><![CDATA[ <example caption='IQ result to accept connection'><![CDATA[
<iq type='result' <iq type='result'
id='pass2' id='pass2'
@ -133,7 +133,7 @@
to='pass.jabber.org'> to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/> <query xmlns='jabber:iq:pass'/>
</iq> </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>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> <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> </section1>
@ -152,7 +152,7 @@
<proxy port='43253'>1.2.3.4</proxy> <proxy port='43253'>1.2.3.4</proxy>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Acknowledgement of expiration'><![CDATA[ <example caption='Acknowledgement of expiration'><![CDATA[
<iq type='result' <iq type='result'
id='pass3' id='pass3'
@ -160,7 +160,7 @@
to='pass.jabber.org'> to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/> <query xmlns='jabber:iq:pass'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='oneshot'> <section2 topic='oneshot'>
<p>This tells the server to listen once, and then close the port. Even if the &lt;expire/&gt; has not been met, the &lt;oneshot/&gt; overrides that and shuts down the listening port. When this happens the server notifies the client with the following packet:</p> <p>This tells the server to listen once, and then close the port. Even if the &lt;expire/&gt; has not been met, the &lt;oneshot/&gt; 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 @@
<proxy port='43253'>1.2.3.4</proxy> <proxy port='43253'>1.2.3.4</proxy>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client acknowledges closing of oneshot port'><![CDATA[ <example caption='Client acknowledges closing of oneshot port'><![CDATA[
<iq type='result' <iq type='result'
id='pass4' id='pass4'
@ -183,7 +183,7 @@
to='pass.jabber.org'> to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/> <query xmlns='jabber:iq:pass'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='close'> <section2 topic='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> <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 @@
<proxy port='43253'>1.2.3.4</proxy> <proxy port='43253'>1.2.3.4</proxy>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges port closing request'><![CDATA[ <example caption='Server acknowledges port closing request'><![CDATA[
<iq type='result' <iq type='result'
id='pass5' id='pass5'
@ -205,7 +205,7 @@
from='pass.jabber.org'> from='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/> <query xmlns='jabber:iq:pass'/>
</iq> </iq>
]]></example> ]]></example>
<table caption='Error Codes'> <table caption='Error Codes'>
<tr> <tr>
<th>Code</th> <th>Code</th>
@ -246,7 +246,7 @@
from='you@jabber.org/resource'> from='you@jabber.org/resource'>
<query xmlns='jabber:iq:pass'/> <query xmlns='jabber:iq:pass'/>
</iq> </iq>
]]></example> ]]></example>
<p>The other client SHOULD send back:</p> <p>The other client SHOULD send back:</p>
<example><![CDATA[ <example><![CDATA[
<iq type='result' <iq type='result'
@ -257,7 +257,7 @@
<client>4.3.2.1</client> <client>4.3.2.1</client>
</query> </query>
</iq> </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 &lt;client/&gt; information upon a connection.</p> <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 &lt;client/&gt; information upon a connection.</p>
</section2> </section2>
<section2 topic='Denying a Connection'> <section2 topic='Denying a Connection'>
@ -273,7 +273,7 @@
<proxy port='43523'>1.2.3.4</proxy> <proxy port='43523'>1.2.3.4</proxy>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Your client would send back:</p> <p>Your client would send back:</p>
<example><![CDATA[ <example><![CDATA[
<iq type='error' <iq type='error'
@ -288,7 +288,7 @@
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<table caption='Error Codes'> <table caption='Error Codes'>
<tr> <tr>
<th>Code</th> <th>Code</th>
@ -354,6 +354,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

26
xep-0004.xml
View File

@ -169,7 +169,7 @@
<option label='option-label'><value>option-value</value></option> <option label='option-label'><value>option-value</value></option>
</field> </field>
</x> </x>
]]></code> ]]></code>
<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 &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 &lt;title/&gt; and &lt;instructions/&gt; 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 &lt;instructions/&gt; element MAY be included.</p> <p>The OPTIONAL &lt;title/&gt; and &lt;instructions/&gt; 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 &lt;instructions/&gt; element MAY be included.</p>
<section2 topic='Form Types' anchor='protocol-formtypes'> <section2 topic='Form Types' anchor='protocol-formtypes'>
@ -299,7 +299,7 @@
. .
. .
</x> </x>
]]></code> ]]></code>
<p>Each of these elements MUST contain one or more &lt;field/&gt; children. The &lt;reported/&gt; element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the &lt;field/&gt; elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a &lt;value/&gt; element. Each &lt;item/&gt; element defines one item in the result set, and MUST contain each field specified in the &lt;reported/&gt; element (although the XML character data of the &lt;value/&gt; element MAY be null).</p> <p>Each of these elements MUST contain one or more &lt;field/&gt; children. The &lt;reported/&gt; element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the &lt;field/&gt; elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a &lt;value/&gt; element. Each &lt;item/&gt; element defines one item in the result set, and MUST contain each field specified in the &lt;reported/&gt; element (although the XML character data of the &lt;value/&gt; element MAY be null).</p>
</section2> </section2>
</section1> </section1>
@ -321,7 +321,7 @@
node='create' node='create'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<p>The hosting service then returns a data form to the user:</p> <p>The hosting service then returns a data form to the user:</p>
<example caption="Service Returns Bot Creation Form"><![CDATA[ <example caption="Service Returns Bot Creation Form"><![CDATA[
<iq from='joogle@botster.shakespeare.lit' <iq from='joogle@botster.shakespeare.lit'
@ -388,7 +388,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The user then submits the configuration form:</p> <p>The user then submits the configuration form:</p>
<example caption="User Submits Bot Creation Form"><![CDATA[ <example caption="User Submits Bot Creation Form"><![CDATA[
<iq from='romeo@montague.net/home' <iq from='romeo@montague.net/home'
@ -432,7 +432,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service then returns the results to the user:</p> <p>The service then returns the results to the user:</p>
<example caption="Service Returns Bot Creation Result"><![CDATA[ <example caption="Service Returns Bot Creation Result"><![CDATA[
<iq from='joogle@botster.shakespeare.lit' <iq from='joogle@botster.shakespeare.lit'
@ -471,7 +471,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Search' anchor='examples-search'> <section2 topic='Search' anchor='examples-search'>
<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> <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>
@ -485,7 +485,7 @@
node='search' node='search'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Returns Search Form"><![CDATA[ <example caption="Service Returns Search Form"><![CDATA[
<iq from='joogle@botster.shakespeare.lit' <iq from='joogle@botster.shakespeare.lit'
to='juliet@capulet.com/chamber' to='juliet@capulet.com/chamber'
@ -505,7 +505,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption="User Submits Search Form"><![CDATA[ <example caption="User Submits Search Form"><![CDATA[
<iq from='juliet@capulet.com/chamber' <iq from='juliet@capulet.com/chamber'
to='joogle@botster.shakespeare.lit' to='joogle@botster.shakespeare.lit'
@ -521,7 +521,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Returns Search Results"><![CDATA[ <example caption="Service Returns Search Results"><![CDATA[
<iq from='joogle@botster.shakespeare.lit' <iq from='joogle@botster.shakespeare.lit'
to='juliet@capulet.com/chamber' to='juliet@capulet.com/chamber'
@ -580,7 +580,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Service Discovery' anchor='disco'> <section1 topic='Service Discovery' anchor='disco'>
@ -592,7 +592,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery information response"><![CDATA[ <example caption="Service Discovery information response"><![CDATA[
<iq type='result' <iq type='result'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
@ -604,7 +604,7 @@
... ...
</query> </query>
</iq> </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 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>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
@ -733,7 +733,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Changes in Final State' anchor='final-changes'> <section1 topic='Changes in Final State' anchor='final-changes'>
<p>The following substantive protocol changes have been made while this specification has been in the Final state:</p> <p>The following substantive protocol changes have been made while this specification has been in the Final state:</p>

12
xep-0009.xml
View File

@ -89,7 +89,7 @@
</methodCall> </methodCall>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='A typical response'><![CDATA[ <example caption='A typical response'><![CDATA[
<iq type='result' <iq type='result'
from='responder@company-a.com/jrpc-server' from='responder@company-a.com/jrpc-server'
@ -105,7 +105,7 @@
</methodResponse> </methodResponse>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:</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>
<example caption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[ <example caption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[
<iq type='error' <iq type='error'
@ -126,7 +126,7 @@
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Service Discovery' anchor='disco'> <section1 topic='Service Discovery' anchor='disco'>
<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>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>
@ -137,7 +137,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq type='result' <iq type='result'
to='requester@company-b.com/jrpc-client' to='requester@company-b.com/jrpc-client'
@ -148,7 +148,7 @@
<feature var='jabber:iq:rpc'/> <feature var='jabber:iq:rpc'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<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>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>
@ -324,6 +324,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

2
xep-0011.xml
View File

@ -471,7 +471,7 @@
<xs:element name='ns' type='xs:string'/> <xs:element name='ns' type='xs:string'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Future Considerations'> <section1 topic='Future Considerations'>
<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 '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>

28
xep-0012.xml
View File

@ -87,7 +87,7 @@
type='get'> type='get'>
<query xmlns='jabber:iq:last'/> <query xmlns='jabber:iq:last'/>
</iq> </iq>
]]></example> ]]></example>
<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 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>
<example caption='Last Activity Response'><![CDATA[ <example caption='Last Activity Response'><![CDATA[
<iq from='juliet@capulet.com' <iq from='juliet@capulet.com'
@ -96,7 +96,7 @@
type='result'> type='result'>
<query xmlns='jabber:iq:last' seconds='903'/> <query xmlns='jabber:iq:last' seconds='903'/>
</iq> </iq>
]]></example> ]]></example>
<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> <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> <ol>
<li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li> <li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li>
@ -114,7 +114,7 @@
type='get'> type='get'>
<query xmlns='jabber:iq:last'/> <query xmlns='jabber:iq:last'/>
</iq> </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>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> <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>
<example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[ <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
@ -126,7 +126,7 @@
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<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> <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>
<example caption='Last Activity Response by Server'><![CDATA[ <example caption='Last Activity Response by Server'><![CDATA[
<iq from='juliet@capulet.com' <iq from='juliet@capulet.com'
@ -135,7 +135,7 @@
type='result'> type='result'>
<query xmlns='jabber:iq:last' seconds='903'>Heading Home</query> <query xmlns='jabber:iq:last' seconds='903'>Heading Home</query>
</iq> </iq>
]]></example> ]]></example>
<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 &lt;status/&gt; element contained the text "Heading Home".</p> <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 &lt;status/&gt; 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 &lt;query/&gt; element whose 'seconds' attribute is set to a value of '0'.</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 &lt;query/&gt; element whose 'seconds' attribute is set to a value of '0'.</p>
</section1> </section1>
@ -148,7 +148,7 @@
type='get'> type='get'>
<query xmlns='jabber:iq:last'/> <query xmlns='jabber:iq:last'/>
</iq> </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 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> <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>
<example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[ <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
@ -160,7 +160,7 @@
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<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> <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>
<example caption='Last Activity Response by Client'><![CDATA[ <example caption='Last Activity Response by Client'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
@ -169,7 +169,7 @@
type='result'> type='result'>
<query xmlns='jabber:iq:last' seconds='123'/> <query xmlns='jabber:iq:last' seconds='123'/>
</iq> </iq>
]]></example> ]]></example>
<p>In the foregoing example, the user has been idle for about two minutes.</p> <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>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>
<example caption='Service Unavailable Error'><![CDATA[ <example caption='Service Unavailable Error'><![CDATA[
@ -181,7 +181,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<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> <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> </section1>
<section1 topic='Server and Component Query' anchor='server'> <section1 topic='Server and Component Query' anchor='server'>
@ -193,7 +193,7 @@
type='get'> type='get'>
<query xmlns='jabber:iq:last'/> <query xmlns='jabber:iq:last'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Last Activity Response from Server or Service'><![CDATA[ <example caption='Last Activity Response from Server or Service'><![CDATA[
<iq from='capulet.com' <iq from='capulet.com'
id='last3' id='last3'
@ -201,7 +201,7 @@
type='result'> type='result'>
<query xmlns='jabber:iq:last' seconds='123456'/> <query xmlns='jabber:iq:last' seconds='123456'/>
</iq> </iq>
]]></example> ]]></example>
<p>In this example, the server has been running for a little more than 34 hours.</p> <p>In this example, the server has been running for a little more than 34 hours.</p>
</section1> </section1>
<section1 topic='Determining Support' anchor='support'> <section1 topic='Determining Support' anchor='support'>
@ -213,7 +213,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Responding entity communicates protocol support'><![CDATA[ <example caption='Responding entity communicates protocol support'><![CDATA[
<iq from='jabber.org' <iq from='jabber.org'
id='disco1' id='disco1'
@ -223,7 +223,7 @@
<feature var='jabber:iq:last'/> <feature var='jabber:iq:last'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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>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>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -270,6 +270,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

34
xep-0013.xml
View File

@ -124,7 +124,7 @@
<iq type='get' to='montague.net'> <iq type='get' to='montague.net'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Reply to Discovery Request'><![CDATA[ <example caption='Server Reply to Discovery Request'><![CDATA[
<iq type='result' <iq type='result'
from='montague.net' from='montague.net'
@ -133,7 +133,7 @@
<feature var='http://jabber.org/protocol/offline'/> <feature var='http://jabber.org/protocol/offline'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the server supports this protocol, it MUST return a &lt;feature/&gt; element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p> <p>If the server supports this protocol, it MUST return a &lt;feature/&gt; element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
</section2> </section2>
<section2 topic='Requesting Number of Messages' anchor='request-number'> <section2 topic='Requesting Number of Messages' anchor='request-number'>
@ -144,7 +144,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/offline'/> node='http://jabber.org/protocol/offline'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p> <p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p>
<example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[ <example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'> <iq type='result' to='romeo@montague.net/orchard'>
@ -164,7 +164,7 @@
</x> </x>
</query> </query>
</iq> </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>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>
</section2> </section2>
<section2 topic='Requesting Message Headers' anchor='request-headers'> <section2 topic='Requesting Message Headers' anchor='request-headers'>
@ -174,7 +174,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'/> node='http://jabber.org/protocol/offline'/>
</iq> </iq>
]]></example> ]]></example>
<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>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>
<example caption='Server Provides Offline Message Headers'><![CDATA[ <example caption='Server Provides Offline Message Headers'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'> <iq type='result' to='romeo@montague.net/orchard'>
@ -202,7 +202,7 @@
name='juliet@capulet.com/balcony'/> name='juliet@capulet.com/balcony'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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 &notfound; 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>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 &notfound; 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> <p>The syntax and semantics of the attributes are as follows:</p>
<ul> <ul>
@ -220,7 +220,7 @@
node='2003-02-27T22:52:37.225Z'/> node='2003-02-27T22:52:37.225Z'/>
</offline> </offline>
</iq> </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 &notfound; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p> <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 &notfound; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p>
<example caption='Server Provides Offline Messages'><![CDATA[ <example caption='Server Provides Offline Messages'><![CDATA[
<message to='romeo@montague.net' from='juliet@capulet.com/balcony'> <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@ -231,7 +231,7 @@
</message> </message>
<iq type='result' to='user@domain/resource' id='view1'/> <iq type='result' to='user@domain/resource' id='view1'/>
]]></example> ]]></example>
<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> <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> </section2>
<section2 topic='Removing Specific Messages' anchor='remove-specific'> <section2 topic='Removing Specific Messages' anchor='remove-specific'>
@ -246,11 +246,11 @@
node='2003-02-27T22:52:37.225Z'/> node='2003-02-27T22:52:37.225Z'/>
</offline> </offline>
</iq> </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 &notfound; error. Otherwise, the server MUST remove the messages and inform the user:</p> <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 &notfound; error. Otherwise, the server MUST remove the messages and inform the user:</p>
<example caption='Server Informs User of Removal'><![CDATA[ <example caption='Server Informs User of Removal'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='remove1'/> <iq type='result' to='romeo@montague.net/orchard' id='remove1'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving All Messages' anchor='retrieve-all'> <section2 topic='Retrieving All Messages' anchor='retrieve-all'>
<p>The user retrieves all message by sending the "fetch" command:</p> <p>The user retrieves all message by sending the "fetch" command:</p>
@ -260,7 +260,7 @@
<fetch/> <fetch/>
</offline> </offline>
</iq> </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 &notfound; error. Otherwise, the server MUST retrieve all messages and inform the user:</p> <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 &notfound; error. Otherwise, the server MUST retrieve all messages and inform the user:</p>
<example caption='Server Sends All Messages and Informs User of Successful Fetch'><![CDATA[ <example caption='Server Sends All Messages and Informs User of Successful Fetch'><![CDATA[
<message to='romeo@montague.net' from='juliet@capulet.com/balcony'> <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@ -271,7 +271,7 @@
</message> </message>
<iq type='result' to='romeo@montague.net/orchard' id='fetch1'/> <iq type='result' to='romeo@montague.net/orchard' id='fetch1'/>
]]></example> ]]></example>
<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> <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> </section2>
<section2 topic='Removing All Messages' anchor='remove-all'> <section2 topic='Removing All Messages' anchor='remove-all'>
@ -282,11 +282,11 @@
<purge/> <purge/>
</offline> </offline>
</iq> </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 &notfound; error. Otherwise, the server MUST remove all messages and inform the user:</p> <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 &notfound; error. Otherwise, the server MUST remove all messages and inform the user:</p>
<example caption='Server Informs User of Successful Purge'><![CDATA[ <example caption='Server Informs User of Successful Purge'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='purge1'/> <iq type='result' to='romeo@montague.net/orchard' id='purge1'/>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Protocol Flow' anchor='flow'> <section1 topic='Protocol Flow' anchor='flow'>
@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc.
<doc>XEP-0013</doc> <doc>XEP-0013</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'> <section2 topic='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> <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.
type='text-single' type='text-single'
label='N/A'/> label='N/A'/>
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

112
xep-0016.xml
View File

@ -132,7 +132,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></code> ]]></code>
<p>If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID. JIDs SHOULD be matched in the following order:</p> <p>If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID. JIDs SHOULD be matched in the following order:</p>
<ol> <ol>
<li>&lt;user@domain/resource&gt; (only that resource matches)</li> <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
@ -176,7 +176,7 @@
<iq from='romeo@example.net/orchard' type='get' id='getlist1'> <iq from='romeo@example.net/orchard' type='get' id='getlist1'>
<query xmlns='jabber:iq:privacy'/> <query xmlns='jabber:iq:privacy'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server sends names of privacy lists to client, preceded by active list and default list'><![CDATA[ <example caption='Server sends names of privacy lists to client, preceded by active list and default list'><![CDATA[
<iq type='result' id='getlist1' to='romeo@example.net/orchard'> <iq type='result' id='getlist1' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
@ -187,14 +187,14 @@
<list name='special'/> <list name='special'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client requests a privacy list from server'><![CDATA[ <example caption='Client requests a privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist2'> <iq from='romeo@example.net/orchard' type='get' id='getlist2'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
<list name='public'/> <list name='public'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server sends a privacy list to client'><![CDATA[ <example caption='Server sends a privacy list to client'><![CDATA[
<iq type='result' id='getlist2' to='romeo@example.net/orchard'> <iq type='result' id='getlist2' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
@ -207,14 +207,14 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client requests another privacy list from server'><![CDATA[ <example caption='Client requests another privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist3'> <iq from='romeo@example.net/orchard' type='get' id='getlist3'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
<list name='private'/> <list name='private'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server sends another privacy list to client'><![CDATA[ <example caption='Server sends another privacy list to client'><![CDATA[
<iq type='result' id='getlist3' to='romeo@example.net/orchard'> <iq type='result' id='getlist3' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
@ -227,14 +227,14 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client requests yet another privacy list from server'><![CDATA[ <example caption='Client requests yet another privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist4'> <iq from='romeo@example.net/orchard' type='get' id='getlist4'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
<list name='special'/> <list name='special'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server sends yet another privacy list to client'><![CDATA[ <example caption='Server sends yet another privacy list to client'><![CDATA[
<iq type='result' id='getlist4' to='romeo@example.net/orchard'> <iq type='result' id='getlist4' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'> <query xmlns='jabber:iq:privacy'>
@ -255,7 +255,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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>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 &lt;item-not-found/&gt; stanza error to the user:</p> <p>If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
<example caption='Client attempts to retrieve non-existent list'><![CDATA[ <example caption='Client attempts to retrieve non-existent list'><![CDATA[
@ -268,7 +268,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </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 &lt;bad request/&gt; stanza error to the user:</p> <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 &lt;bad request/&gt; stanza error to the user:</p>
<example caption='Client attempts to retrieve more than one list'><![CDATA[ <example caption='Client attempts to retrieve more than one list'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='getlist6'> <iq to='romeo@example.net/orchard' type='error' id='getlist6'>
@ -282,7 +282,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Managing Active Lists" anchor="protocol-active"> <section2 topic="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 &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;active/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p> <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 &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;active/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@ -292,11 +292,11 @@
<active name='special'/> <active name='special'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The server MUST activate and apply the requested list before sending the result back to the client.</p> <p>The server MUST activate and apply the requested list before sending the result back to the client.</p>
<example caption='Server acknowledges success of active list change'><![CDATA[ <example caption='Server acknowledges success of active list change'><![CDATA[
<iq type='result' id='active1' to='romeo@example.net/orchard'/> <iq type='result' id='active1' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
<p>If the user attempts to set an active list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p> <p>If the user attempts to set an active list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
<example caption='Client attempts to set a non-existent list as active'><![CDATA[ <example caption='Client attempts to set a non-existent list as active'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='active2'> <iq to='romeo@example.net/orchard' type='error' id='active2'>
@ -308,7 +308,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>In order to decline the use of any active list, the connected resource MUST send an empty &lt;active/&gt; element with no 'name' attribute.</p> <p>In order to decline the use of any active list, the connected resource MUST send an empty &lt;active/&gt; element with no 'name' attribute.</p>
<example caption='Client declines the use of active lists'><![CDATA[ <example caption='Client declines the use of active lists'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='active3'> <iq from='romeo@example.net/orchard' type='set' id='active3'>
@ -316,10 +316,10 @@
<active/> <active/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges success of declining any active list'><![CDATA[ <example caption='Server acknowledges success of declining any active list'><![CDATA[
<iq type='result' id='active3' to='romeo@example.net/orchard'/> <iq type='result' id='active3' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Managing the Default List" anchor="protocol-default"> <section2 topic="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 &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;default/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p> <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 &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;default/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@ -329,10 +329,10 @@
<default name='special'/> <default name='special'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges success of default list change'><![CDATA[ <example caption='Server acknowledges success of default list change'><![CDATA[
<iq type='result' id='default1' to='romeo@example.net/orchard'/> <iq type='result' id='default1' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
<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 &lt;conflict/&gt; stanza error to the sending resource:</p> <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 &lt;conflict/&gt; stanza error to the sending resource:</p>
<example caption='Client attempts to change the default list but that list is in use by another resource'><![CDATA[ <example caption='Client attempts to change the default list but that list is in use by another resource'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='default1'> <iq to='romeo@example.net/orchard' type='error' id='default1'>
@ -344,7 +344,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the user attempts to set a default list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p> <p>If the user attempts to set a default list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
<example caption='Client attempts to set a non-existent list as default'><![CDATA[ <example caption='Client attempts to set a non-existent list as default'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='default1'> <iq to='romeo@example.net/orchard' type='error' id='default1'>
@ -356,7 +356,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<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 &lt;default/&gt; element with no 'name' attribute.</p> <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 &lt;default/&gt; element with no 'name' attribute.</p>
<example caption='Client declines the use of the default list'><![CDATA[ <example caption='Client declines the use of the default list'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='default2'> <iq from='romeo@example.net/orchard' type='set' id='default2'>
@ -364,10 +364,10 @@
<default/> <default/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges success of declining any default list'><![CDATA[ <example caption='Server acknowledges success of declining any default list'><![CDATA[
<iq type='result' id='default2' to='romeo@example.net/orchard'/> <iq type='result' id='default2' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
<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 &lt;conflict/&gt; error to the sending resource:</p> <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 &lt;conflict/&gt; error to the sending resource:</p>
<example caption='Client attempts to decline a default list but that list is in use by another resource'><![CDATA[ <example caption='Client attempts to decline a default list but that list is in use by another resource'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='default3'> <iq to='romeo@example.net/orchard' type='error' id='default3'>
@ -379,7 +379,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Editing a Privacy List" anchor="protocol-edit"> <section2 topic="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 &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains one &lt;list/&gt; child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The &lt;list/&gt; element MUST contain one or more &lt;item/&gt; elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").</p> <p>In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains one &lt;list/&gt; child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The &lt;list/&gt; element MUST contain one or more &lt;item/&gt; 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 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges success of list edit'><![CDATA[ <example caption='Server acknowledges success of list edit'><![CDATA[
<iq type='result' id='edit1' to='romeo@example.net/orchard'/> <iq type='result' id='edit1' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
<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>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> <p>The server MUST now send a "privacy list push" to all connected resources:</p>
<example caption='Privacy list push on list edit'><![CDATA[ <example caption='Privacy list push on list edit'><![CDATA[
@ -417,7 +417,7 @@
<list name='public'/> <list name='public'/>
</query> </query>
</iq> </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> <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>
<example caption='Acknowledging receipt of privacy list pushes'><![CDATA[ <example caption='Acknowledging receipt of privacy list pushes'><![CDATA[
<iq from='romeo@example.net/orchard' <iq from='romeo@example.net/orchard'
@ -427,7 +427,7 @@
<iq from='romeo@example.net/home' <iq from='romeo@example.net/home'
type='result' type='result'
id='push2'/> id='push2'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Adding a New Privacy List" anchor="protocol-add"> <section2 topic="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> <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 @@
<list name='private'/> <list name='private'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges success of list removal'><![CDATA[ <example caption='Server acknowledges success of list removal'><![CDATA[
<iq type='result' id='remove1' to='romeo@example.net/orchard'/> <iq type='result' id='remove1' to='romeo@example.net/orchard'/>
]]></example> ]]></example>
<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 &lt;conflict/&gt; 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 &lt;item-not-found/&gt; stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user.</p> <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 &lt;conflict/&gt; 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 &lt;item-not-found/&gt; stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user.</p>
</section2> </section2>
<section2 topic="Blocking Messages" anchor="protocol-message"> <section2 topic="Blocking Messages" anchor="protocol-message">
@ -461,7 +461,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.</p> <p>As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.</p>
<example caption='User blocks based on roster group'><![CDATA[ <example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg2'> <iq from='romeo@example.net/orchard' type='set' id='msg2'>
@ -476,7 +476,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.</p> <p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[ <example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg3'> <iq from='romeo@example.net/orchard' type='set' id='msg3'>
@ -491,7 +491,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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 messages from any entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[ <example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg4'> <iq from='romeo@example.net/orchard' type='set' id='msg4'>
@ -503,7 +503,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive messages from any other users.</p> <p>As a result of creating and applying the foregoing list, the user will not receive messages from any other users.</p>
</section2> </section2>
<section2 topic="Blocking Inbound Presence Notifications" anchor="protocol-presencein"> <section2 topic="Blocking Inbound Presence Notifications" anchor="protocol-presencein">
@ -522,7 +522,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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> <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>
<example caption='User blocks based on roster group'><![CDATA[ <example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin2'> <iq from='romeo@example.net/orchard' type='set' id='presin2'>
@ -537,7 +537,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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> <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>
<example caption='User blocks based on subscription type'><![CDATA[ <example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin3'> <iq from='romeo@example.net/orchard' type='set' id='presin3'>
@ -552,7 +552,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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 entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[ <example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin4'> <iq from='romeo@example.net/orchard' type='set' id='presin4'>
@ -564,7 +564,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</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> <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> </section2>
@ -584,7 +584,7 @@
</list> </list>
</query> </query>
</iq> </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> <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>
<example caption='User blocks based on roster group'><![CDATA[ <example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout2'> <iq from='romeo@example.net/orchard' type='set' id='presout2'>
@ -599,7 +599,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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> <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>
<example caption='User blocks based on subscription type'><![CDATA[ <example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout3'> <iq from='romeo@example.net/orchard' type='set' id='presout3'>
@ -614,7 +614,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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 entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[ <example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout4'> <iq from='romeo@example.net/orchard' type='set' id='presout4'>
@ -626,7 +626,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</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> <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> </section2>
@ -645,7 +645,7 @@
</list> </list>
</query> </query>
</iq> </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> <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>
<example caption='User blocks based on roster group'><![CDATA[ <example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq2'> <iq from='romeo@example.net/orchard' type='set' id='iq2'>
@ -660,7 +660,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.</p> <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[ <example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq3'> <iq from='romeo@example.net/orchard' type='set' id='iq3'>
@ -675,7 +675,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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 entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[ <example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq4'> <iq from='romeo@example.net/orchard' type='set' id='iq4'>
@ -687,7 +687,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.</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> </section2>
<section2 topic="Blocking All Communication" anchor="protocol-all"> <section2 topic="Blocking All Communication" anchor="protocol-all">
@ -703,7 +703,7 @@
</list> </list>
</query> </query>
</iq> </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> <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>
<example caption='User blocks based on roster group'><![CDATA[ <example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all2'> <iq from='romeo@example.net/orchard' type='set' id='all2'>
@ -716,7 +716,7 @@
</list> </list>
</query> </query>
</iq> </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, any entities in the specified roster group.</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 entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[ <example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all3'> <iq from='romeo@example.net/orchard' type='set' id='all3'>
@ -729,7 +729,7 @@
</list> </list>
</query> </query>
</iq> </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, 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 entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[ <example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all4'> <iq from='romeo@example.net/orchard' type='set' id='all4'>
@ -739,7 +739,7 @@
</list> </list>
</query> </query>
</iq> </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, any other users.</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> </section2>
<section2 topic="Blocked Entity Attempts to Communicate with User" anchor="protocol-error"> <section2 topic="Blocked Entity Attempts to Communicate with User" anchor="protocol-error">
@ -757,7 +757,7 @@
id='probing1'> id='probing1'>
<query xmlns='jabber:iq:version'/> <query xmlns='jabber:iq:version'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server returns error to blocked entity'><![CDATA[ <example caption='Server returns error to blocked entity'><![CDATA[
<iq type='error' <iq type='error'
from='romeo@example.net' from='romeo@example.net'
@ -769,7 +769,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </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 &notacceptable; error:</p> <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 &notacceptable; error:</p>
<example caption='Error: contact is blocked'><![CDATA[ <example caption='Error: contact is blocked'><![CDATA[
<message type='error' from='romeo@montague.net' to='juliet@capulet.com'> <message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
@ -778,7 +778,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics"> <section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics">
<p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p> <p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p>
@ -801,7 +801,7 @@
</list> </list>
</query> </query>
</iq> </iq>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
@ -814,7 +814,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery information response"><![CDATA[ <example caption="Service Discovery information response"><![CDATA[
<iq from='example.com' <iq from='example.com'
id='disco1' id='disco1'
@ -826,7 +826,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -962,7 +962,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='Author Note' anchor='authornote'>

12
xep-0020.xml
View File

@ -120,7 +120,7 @@
</x> </x>
</feature> </feature>
</iq> </iq>
]]></example> ]]></example>
<example caption="Responding entity sends preferred option values"><![CDATA[ <example caption="Responding entity sends preferred option values"><![CDATA[
<iq type='result' <iq type='result'
id='neg1' id='neg1'
@ -140,7 +140,7 @@
</x> </x>
</feature> </feature>
</iq> </iq>
]]></example> ]]></example>
<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 <link url='#security'>Security Considerations</link>.</p> <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 <link url='#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> <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>
<example caption="Responding entity does not support feature negotiation"><![CDATA[ <example caption="Responding entity does not support feature negotiation"><![CDATA[
@ -160,7 +160,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<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 &lt;text/&gt; element.</p> <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 &lt;text/&gt; element.</p>
<example caption="Responding entity does not support a feature"><![CDATA[ <example caption="Responding entity does not support a feature"><![CDATA[
<iq type='error' <iq type='error'
@ -180,7 +180,7 @@
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>times-to-meet</text> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>times-to-meet</text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a &notacceptable; error, and SHOULD specify the relevant feature(s) in the XMPP &lt;text/&gt; element.</p> <p>If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a &notacceptable; error, and SHOULD specify the relevant feature(s) in the XMPP &lt;text/&gt; element.</p>
<example caption="Responding entity supports no options"><![CDATA[ <example caption="Responding entity supports no options"><![CDATA[
<iq type='error' <iq type='error'
@ -200,7 +200,7 @@
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>places-to-meet</text> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>places-to-meet</text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Querying for Negotiable Features" anchor='protocol-query'> <section2 topic="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 &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p> <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 &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p>
@ -314,7 +314,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='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>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>

26
xep-0022.xml
View File

@ -121,7 +121,7 @@
<composing/> <composing/>
</x> </x>
</message> </message>
]]></example> ]]></example>
<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>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> <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> </section2>
@ -137,7 +137,7 @@
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p> <p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p>
<ul> <ul>
<li>The element must contain only a jabber:x:event extension. Standard message elements such as &lt;subject/&gt;, &lt;body/&gt;, MUST NOT be included.</li> <li>The element must contain only a jabber:x:event extension. Standard message elements such as &lt;subject/&gt;, &lt;body/&gt;, MUST NOT be included.</li>
@ -160,7 +160,7 @@
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<example caption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[ <example caption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[
<message <message
from='romeo@montague.net' from='romeo@montague.net'
@ -169,7 +169,7 @@
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>The lack of an &lt;composing/&gt; 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>The lack of an &lt;composing/&gt; 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>
</section2> </section2>
</section1> </section1>
@ -186,7 +186,7 @@ SEND: <message to='romeo@montague.net' id='message22'>
<composing/> <composing/>
</x> </x>
</message> </message>
]]></example> ]]></example>
<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> <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>
<example caption='Receiving the offline event'><![CDATA[ <example caption='Receiving the offline event'><![CDATA[
RECV: <message RECV: <message
@ -197,7 +197,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.</p> <p>Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.</p>
<example caption='Juliet receives notification of message delivery'><![CDATA[ <example caption='Juliet receives notification of message delivery'><![CDATA[
RECV: <message RECV: <message
@ -208,7 +208,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.</p> <p>Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.</p>
<example caption='Juliet receives notification of message display'><![CDATA[ <example caption='Juliet receives notification of message display'><![CDATA[
RECV: <message RECV: <message
@ -219,7 +219,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.</p> <p>Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.</p>
<example caption='Juliet receives notification of message composing'><![CDATA[ <example caption='Juliet receives notification of message composing'><![CDATA[
RECV: <message RECV: <message
@ -230,7 +230,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.</p> <p>Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.</p>
<example caption='Juliet receives cancellation of message composing'><![CDATA[ <example caption='Juliet receives cancellation of message composing'><![CDATA[
RECV: <message RECV: <message
@ -240,7 +240,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.</p> <p>Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.</p>
<example caption='Juliet receives a second notification of message composing'><![CDATA[ <example caption='Juliet receives a second notification of message composing'><![CDATA[
RECV: <message RECV: <message
@ -251,7 +251,7 @@ RECV: <message
<id>message22</id> <id>message22</id>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Romeo finally sends his reply, and requests composing events related to it.</p> <p>Romeo finally sends his reply, and requests composing events related to it.</p>
<example caption='Romeo replies'><![CDATA[ <example caption='Romeo replies'><![CDATA[
SEND: <message to='juliet@capulet.com' id='GabberMessage43'> SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
@ -260,7 +260,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<composing/> <composing/>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Implementation Notes'> <section1 topic='Implementation Notes'>
@ -319,7 +319,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Open Issues'> <section1 topic='Open Issues'>

2
xep-0023.xml
View File

@ -168,7 +168,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Open Issues'> <section1 topic='Open Issues'>

4
xep-0027.xml
View File

@ -163,7 +163,7 @@
<xs:element name='x' type='xs:string'/> <xs:element name='x' type='xs:string'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='jabber:x:signed' anchor='schemas-signed'> <section2 topic='jabber:x:signed' anchor='schemas-signed'>
<code><![CDATA[ <code><![CDATA[
@ -185,7 +185,7 @@
<xs:element name='x' type='xs:string'/> <xs:element name='x' type='xs:string'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

68
xep-0030.xml
View File

@ -276,7 +276,7 @@
id='info1'> id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.)</p> <p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.)</p>
<p>Each &lt;identity/&gt; element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the &lt;identity/&gt; element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the &lt;query/&gt; element MAY include multiple &lt;identity/&gt; elements with the same category+type but with different 'xml:lang' values, however the &lt;query/&gt; element MUST NOT include multiple &lt;identity/&gt; elements with the same category+type+xml:lang but with different 'name' values).</p> <p>Each &lt;identity/&gt; element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the &lt;identity/&gt; element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the &lt;query/&gt; element MAY include multiple &lt;identity/&gt; elements with the same category+type but with different 'xml:lang' values, however the &lt;query/&gt; element MUST NOT include multiple &lt;identity/&gt; elements with the same category+type+xml:lang but with different 'name' values).</p>
<p>Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity, and MUST NOT have any children.</p> <p>Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity, and MUST NOT have any children.</p>
@ -304,7 +304,7 @@
<feature var='jabber:iq:version'/> <feature var='jabber:iq:version'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <cite>XMPP Core</cite> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p> <p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <cite>XMPP Core</cite> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p>
<example caption='Target entity does not exist'><![CDATA[ <example caption='Target entity does not exist'><![CDATA[
<iq type='error' <iq type='error'
@ -316,7 +316,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If privacy and security considerations or policies prevent the server or other authoritative entity from returning an &notfound; error, it SHOULD return a &unavailable; error instead:</p> <p>If privacy and security considerations or policies prevent the server or other authoritative entity from returning an &notfound; error, it SHOULD return a &unavailable; error instead:</p>
<example caption='Service unavailable'><![CDATA[ <example caption='Service unavailable'><![CDATA[
<iq type='error' <iq type='error'
@ -328,7 +328,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>When an entity sends a disco#info request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).</p> <p>When an entity sends a disco#info request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).</p>
<example caption='Requesting info from a bare JID'><![CDATA[ <example caption='Requesting info from a bare JID'><![CDATA[
<iq type='get' <iq type='get'
@ -337,7 +337,7 @@
id='info2'> id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; is a registered account:</p> <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; is a registered account:</p>
<example caption='Server replies on behalf of bare JID'><![CDATA[ <example caption='Server replies on behalf of bare JID'><![CDATA[
<iq type='result' <iq type='result'
@ -349,7 +349,7 @@
<feature var='http://jabber.org/protocol/disco#info'/> <feature var='http://jabber.org/protocol/disco#info'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:</p> <p>A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:</p>
<example caption='Querying a specific conference room'><![CDATA[ <example caption='Querying a specific conference room'><![CDATA[
<iq type='get' <iq type='get'
@ -401,7 +401,7 @@
<feature var='jabber:iq:version'/> <feature var='jabber:iq:version'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Info Nodes' anchor='info-nodes'> <section2 topic='Info Nodes' anchor='info-nodes'>
<p>A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as <link url='#items-nodes'>Items Nodes</link> rather than as info nodes:</p> <p>A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as <link url='#items-nodes'>Items Nodes</link> rather than as info nodes:</p>
@ -413,7 +413,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'/> node='http://jabber.org/protocol/commands'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.</p> <p>If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.</p>
<example caption='JID+node result'><![CDATA[ <example caption='JID+node result'><![CDATA[
<iq type='result' <iq type='result'
@ -428,7 +428,7 @@
<feature var='http://jabber.org/protocol/disco#info'/> <feature var='http://jabber.org/protocol/disco#info'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -442,7 +442,7 @@
id='items1'> id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an &lt;item/&gt; child of a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the &lt;item/&gt; child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):</p> <p>The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an &lt;item/&gt; child of a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the &lt;item/&gt; child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):</p>
<example caption='Result-set for all items'><![CDATA[ <example caption='Result-set for all items'><![CDATA[
<iq type='result' <iq type='result'
@ -468,7 +468,7 @@
name='French Translation Service'/> name='French Translation Service'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The &lt;item/&gt; element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.</p> <p>The &lt;item/&gt; element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.</p>
<p>If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:</p> <p>If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:</p>
<example caption='Empty result set'><![CDATA[ <example caption='Empty result set'><![CDATA[
@ -478,7 +478,7 @@
id='items1'> id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>As with disco#info requests, when an entity sends a disco#items request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:</p> <p>As with disco#info requests, when an entity sends a disco#items request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:</p>
<example caption='Requesting items from a bare JID'><![CDATA[ <example caption='Requesting items from a bare JID'><![CDATA[
<iq type='get' <iq type='get'
@ -487,7 +487,7 @@
id='items2'> id='items2'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; has two available resources:</p> <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; has two available resources:</p>
<example caption='Server replies on behalf of bare JID'><![CDATA[ <example caption='Server replies on behalf of bare JID'><![CDATA[
<iq type='result' <iq type='result'
@ -499,7 +499,7 @@
<item jid='juliet@capulet.com/chamber'/> <item jid='juliet@capulet.com/chamber'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Items Nodes' anchor='items-nodes'> <section2 topic='Items Nodes' anchor='items-nodes'>
<p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p> <p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p>
@ -512,7 +512,7 @@
id='items2'> id='items2'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each &lt;item/&gt; element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):</p> <p>If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each &lt;item/&gt; element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):</p>
<example caption='Service returns nodes'><![CDATA[ <example caption='Service returns nodes'><![CDATA[
<iq type='result' <iq type='result'
@ -531,7 +531,7 @@
name='Music from the time of Shakespeare'/> name='Music from the time of Shakespeare'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.</p> <p>There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.</p>
<example caption='Requesting further nodes'><![CDATA[ <example caption='Requesting further nodes'><![CDATA[
<iq type='get' <iq type='get'
@ -541,7 +541,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='music'/> node='music'/>
</iq> </iq>
]]></example> ]]></example>
<p>The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.</p> <p>The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.</p>
<example caption='Service returns further nodes'><![CDATA[ <example caption='Service returns further nodes'><![CDATA[
<iq type='result' <iq type='result'
@ -563,7 +563,7 @@
. .
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The requesting entity can then query further if desired:</p> <p>The requesting entity can then query further if desired:</p>
<example caption='Requesting even more nodes'><![CDATA[ <example caption='Requesting even more nodes'><![CDATA[
<iq type='get' <iq type='get'
@ -573,7 +573,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='music/D'/> node='music/D'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service returns even more nodes'><![CDATA[ <example caption='Service returns even more nodes'><![CDATA[
<iq type='result' <iq type='result'
from='catalog.shakespeare.lit' from='catalog.shakespeare.lit'
@ -589,7 +589,7 @@
name='John Dowland - A Pilgrimes Solace'/> name='John Dowland - A Pilgrimes Solace'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Node Hierarchies' anchor='items-hierarchy'> <section2 topic='Node Hierarchies' anchor='items-hierarchy'>
<p>The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.</p> <p>The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.</p>
@ -616,7 +616,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'/> node='http://jabber.org/protocol/tune'/>
</iq> </iq>
]]></example> ]]></example>
<p>The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:</p> <p>The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:</p>
<example caption='Entity returns multiple items'><![CDATA[ <example caption='Entity returns multiple items'><![CDATA[
<iq from='romeo@montague.net' <iq from='romeo@montague.net'
@ -634,7 +634,7 @@
node='g8k4kds9sd89djf3'/> node='g8k4kds9sd89djf3'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -667,7 +667,7 @@
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Other error conditions may be appropriate depending on the application.</p> <p>Other error conditions may be appropriate depending on the application.</p>
<p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).</p> <p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).</p>
<table caption='Error Conditions'> <table caption='Error Conditions'>
@ -731,7 +731,7 @@
<doc>the document (e.g., XEP) in which this type is specified</doc> <doc>the document (e.g., XEP) in which this type is specified</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
<p>The registrant may register more than one category at a time, each contained in a separate &lt;category/&gt; element. The registrant may also register more than one type at a time, each contained in a separate &lt;type/&gt; child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).</p> <p>The registrant may register more than one category at a time, each contained in a separate &lt;category/&gt; element. The registrant may also register more than one type at a time, each contained in a separate &lt;type/&gt; child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).</p>
</section4> </section4>
<section4 topic='Initial Submission' anchor='registrar-reg-identity-init'> <section4 topic='Initial Submission' anchor='registrar-reg-identity-init'>
@ -760,7 +760,7 @@
<doc>XEP-0030</doc> <doc>XEP-0030</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
<section3 topic='Features Registry' anchor='registrar-reg-features'> <section3 topic='Features Registry' anchor='registrar-reg-features'>
@ -773,7 +773,7 @@
<desc>a natural-language description of the feature</desc> <desc>a natural-language description of the feature</desc>
<doc>the document (e.g., XEP) in which this feature is specified</doc> <doc>the document (e.g., XEP) in which this feature is specified</doc>
</var> </var>
]]></code> ]]></code>
<p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p> <p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p>
</section4> </section4>
</section3> </section3>
@ -787,7 +787,7 @@
<desc>a natural-language description of the node</desc> <desc>a natural-language description of the node</desc>
<doc>the document (e.g., XEP) in which this node is specified</doc> <doc>the document (e.g., XEP) in which this node is specified</doc>
</node> </node>
]]></code> ]]></code>
<p>The registrant may register more than one node at a time, each contained in a separate &lt;node/&gt; element.</p> <p>The registrant may register more than one node at a time, each contained in a separate &lt;node/&gt; element.</p>
</section4> </section4>
</section3> </section3>
@ -797,20 +797,20 @@
<p>The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).</p> <p>The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).</p>
<example caption='Service Discovery Information Request: IRI/URI'><![CDATA[ <example caption='Service Discovery Information Request: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?disco;type=get;request=info xmpp:romeo@montague.net?disco;type=get;request=info
]]></example> ]]></example>
<example caption='Service Discovery Information Request: Resulting Stanza'><![CDATA[ <example caption='Service Discovery Information Request: Resulting Stanza'><![CDATA[
<iq to='romeo@montague.net' type='get'> <iq to='romeo@montague.net' type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Discovery Items Request: IRI/URI'><![CDATA[ <example caption='Service Discovery Items Request: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?disco;type=get;request=items xmpp:romeo@montague.net?disco;type=get;request=items
]]></example> ]]></example>
<example caption='Service Discovery Items Request: Resulting Stanza'><![CDATA[ <example caption='Service Discovery Items Request: Resulting Stanza'><![CDATA[
<iq to='romeo@montague.net' type='get'> <iq to='romeo@montague.net' type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>The following submission registers the "disco" querytype.</p> <p>The following submission registers the "disco" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -850,7 +850,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
</keys> </keys>
</querytype> </querytype>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schemas' anchor='schemas'> <section1 topic='XML Schemas' anchor='schemas'>
@ -916,7 +916,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='disco#items' anchor='schemas-items'> <section2 topic='disco#items' anchor='schemas-items'>
<code><![CDATA[ <code><![CDATA[
@ -970,7 +970,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='Author Note' anchor='authornote'>

2
xep-0033.xml
View File

@ -703,7 +703,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

4
xep-0038.xml
View File

@ -288,7 +288,7 @@
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic="icondef.xml file example"> <section2 topic="icondef.xml file example">
@ -342,7 +342,7 @@
<object mime="audio/x-wav">alert.wav</object> <object mime="audio/x-wav">alert.wav</object>
</icon> </icon>
</icondef> </icondef>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

2
xep-0041.xml
View File

@ -264,7 +264,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

78
xep-0042.xml
View File

@ -118,7 +118,7 @@
<iq type='get' to='domain'> <iq type='get' to='domain'>
<query xmlns='jabber:iq:browse'/> <query xmlns='jabber:iq:browse'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Browse result'><![CDATA[ <example caption='Browse result'><![CDATA[
<iq type='get' to='sender@domain/res' from='domain'> <iq type='get' to='sender@domain/res' from='domain'>
... ...
@ -131,7 +131,7 @@
</item> </item>
... ...
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Creating a Session'> <section2 topic='Creating a Session'>
@ -147,7 +147,7 @@
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
action='create'/> action='create'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Creation result'><![CDATA[ <example caption='Creation result'><![CDATA[
<iq <iq
type='result' to='sender@domain/res' from='jobs.domain'> type='result' to='sender@domain/res' from='jobs.domain'>
@ -161,7 +161,7 @@
expires='30' expires='30'
receivers='1'/> receivers='1'/>
</iq> </iq>
]]></example> ]]></example>
<p>This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The &lt;session/&gt; element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID <note>The exact value of the ID is left to JOBS implementations.</note>.</p> <p>This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The &lt;session/&gt; element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID <note>The exact value of the ID is left to JOBS implementations.</note>.</p>
</section3> </section3>
@ -174,7 +174,7 @@
<iq id='JOBS0' type='get' to='jobs.domain'> <iq id='JOBS0' type='get' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'/> <session xmlns='http://jabber.org/protocol/jobs' action='create'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Parameter statistics result'><![CDATA[ <example caption='Parameter statistics result'><![CDATA[
<iq id='JOBS0' type='result' to='sender@domain/res' from='jobs.domain'> <iq id='JOBS0' type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
@ -199,7 +199,7 @@
min='1'/> min='1'/>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p> <p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p>
@ -209,7 +209,7 @@
<session xmlns='http://jabber.org/protocol/jobs' action='create' <session xmlns='http://jabber.org/protocol/jobs' action='create'
expires='-1'/> expires='-1'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Creation result, with parameters'><![CDATA[ <example caption='Creation result, with parameters'><![CDATA[
<iq type='result' to='sender@domain/res' from='jobs.domain'> <iq type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
@ -222,7 +222,7 @@
expires='-1' expires='-1'
receivers='1'/> receivers='1'/>
</iq> </iq>
]]></example> ]]></example>
<p>The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.</p> <p>The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.</p>
@ -239,7 +239,7 @@
<x xmlns='jabber:x:data'/> <x xmlns='jabber:x:data'/>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<example caption='Creation form result'><![CDATA[ <example caption='Creation form result'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'> <iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
@ -259,7 +259,7 @@
</x> </x>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the &lt;session/&gt; attributes.</p> <p>The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the &lt;session/&gt; attributes.</p>
<p>Using the form-based approach, the session is then created by sending a &lt;session action='create'/&gt; with a form submission (as defined for "jabber:x:data"):</p> <p>Using the form-based approach, the session is then created by sending a &lt;session action='create'/&gt; with a form submission (as defined for "jabber:x:data"):</p>
@ -275,7 +275,7 @@
</x> </x>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<example caption='Creation result (form-based)'><![CDATA[ <example caption='Creation result (form-based)'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'> <iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
@ -288,7 +288,7 @@
expires='300' expires='300'
receivers='1'/> receivers='1'/>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Inviting Receivers'> <section2 topic='Inviting Receivers'>
@ -308,7 +308,7 @@
expires='30' expires='30'
receivers='1'/> receivers='1'/>
</message> </message>
]]></example> ]]></example>
<p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p> <p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p>
<ul> <ul>
@ -327,7 +327,7 @@
id='01234567'> id='01234567'>
<item type='connection' action='invite'>receiver@domain</item> <item type='connection' action='invite'>receiver@domain</item>
</message> </message>
]]></example> ]]></example>
<p>This results in the JOBS service sending the &lt;message/&gt; to each &lt;item/&gt;. Any additional elements (such as a &lt;body/&gt;) are passed onto those invited:</p> <p>This results in the JOBS service sending the &lt;message/&gt; to each &lt;item/&gt;. Any additional elements (such as a &lt;body/&gt;) are passed onto those invited:</p>
<example caption='Invitation message (from JOBS service)'><![CDATA[ <example caption='Invitation message (from JOBS service)'><![CDATA[
<message from='jobs.domain' to='receiver@domain'> <message from='jobs.domain' to='receiver@domain'>
@ -344,7 +344,7 @@
receivers='1'> receivers='1'>
<item type='connection' action='invite'/> <item type='connection' action='invite'/>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Retrieving Session Information'> <section2 topic='Retrieving Session Information'>
@ -357,7 +357,7 @@
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
action='info'/> action='info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The JOBS service responds with all the sessions within the "iq-result". This is the only case where a result can have more than one &lt;session/&gt;.</p> <p>The JOBS service responds with all the sessions within the "iq-result". This is the only case where a result can have more than one &lt;session/&gt;.</p>
<example caption='Information result (all sessions)'><![CDATA[ <example caption='Information result (all sessions)'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'> <iq type='result' from='jobs.domain' to='sender@domain/res'>
@ -382,7 +382,7 @@
expires='30' expires='30'
receivers='1'/> receivers='1'/>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Session-specific'> <section3 topic='Session-specific'>
<p>Alternatively, a client can request the information for a specific session by sending an "iq-get" containing a &lt;session action="info"/&gt; with the ID:</p> <p>Alternatively, a client can request the information for a specific session by sending an "iq-get" containing a &lt;session action="info"/&gt; with the ID:</p>
@ -392,7 +392,7 @@
action='info' action='info'
id='01234567'/> id='01234567'/>
</iq> </iq>
]]></example> ]]></example>
<p>The service responds with an "iq-result" of just the requested session.</p> <p>The service responds with an "iq-result" of just the requested session.</p>
<example caption='Information result (session-specific)'><![CDATA[ <example caption='Information result (session-specific)'><![CDATA[
<iq type='result' from='jobs.domain' sender='sender@domain/res'> <iq type='result' from='jobs.domain' sender='sender@domain/res'>
@ -408,7 +408,7 @@
<item type='connection' action='accept'>sender@domain/res</item> <item type='connection' action='accept'>sender@domain/res</item>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Connecting OOB'> <section2 topic='Connecting OOB'>
@ -422,7 +422,7 @@ jobs/0.4 init
session-id: 01234567 session-id: 01234567
client-jid: sender@domain/res client-jid: sender@domain/res
]]></example> ]]></example>
<p>If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:</p> <p>If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:</p>
@ -430,7 +430,7 @@ client-jid: sender@domain/res
jobs/0.4 auth-challenge jobs/0.4 auth-challenge
confirm: SID00001234 confirm: SID00001234
]]></example> ]]></example>
<p>Once received, the client then sends an "iq-set" containing a &lt;session action="authenticate"/&gt;, which itself contains an &lt;item type='auth' action='confirm'/&gt; with this confirm key:</p> <p>Once received, the client then sends an "iq-set" containing a &lt;session action="authenticate"/&gt;, which itself contains an &lt;item type='auth' action='confirm'/&gt; with this confirm key:</p>
@ -442,7 +442,7 @@ confirm: SID00001234
<item type='auth' action='confirm'>SID00001234</item> <item type='auth' action='confirm'>SID00001234</item>
</session> </session>
</iq>hehe </iq>hehe
]]></example> ]]></example>
<p>The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a &lt;session action="authenticate"/&gt; containing a &lt;item type="auth" action="accept"/&gt; with the accept key:</p> <p>The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a &lt;session action="authenticate"/&gt; containing a &lt;item type="auth" action="accept"/&gt; with the accept key:</p>
@ -455,7 +455,7 @@ confirm: SID00001234
<item type='auth' action='accept'>SID88884321</accept> <item type='auth' action='accept'>SID88884321</accept>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p> <p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p>
@ -463,14 +463,14 @@ confirm: SID00001234
jobs/0.4 auth-response jobs/0.4 auth-response
accept: SID88884321 accept: SID88884321
]]></example> ]]></example>
<p>If the connection is accepted, the JOBS service sends a "connected" packet:</p> <p>If the connection is accepted, the JOBS service sends a "connected" packet:</p>
<example caption='Server CONNECTED'><![CDATA[ <example caption='Server CONNECTED'><![CDATA[
jobs/0.4 connected jobs/0.4 connected
]]></example> ]]></example>
<p>and after this, the data transfer occurs. If this connection is the sender, they may start sending data now (regardless if receivers are connected). If this connection is a receiver, the sender's data immediately follows the terminating "newline".</p> <p>and after this, the data transfer occurs. If this connection is the sender, they may start sending data now (regardless if receivers are connected). If this connection is a receiver, the sender's data immediately follows the terminating "newline".</p>
</section3> </section3>
<section3 topic='Authorizing'> <section3 topic='Authorizing'>
@ -487,7 +487,7 @@ confirm: SID00001234
<item type='connection' action='confirm'>receiver@domain/res</item> <item type='connection' action='confirm'>receiver@domain/res</item>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>One or more &lt;item type="connection" action="confirm/&gt; elements, each specifying a JID to accept/reject. To accept (or reject) a connection, the sender responds with an "iq-result", wrapping each JID in either an &lt;item type="connection" action="accept"/&gt; or &lt;item type="connection" action="reject"/&gt;.</p> <p>One or more &lt;item type="connection" action="confirm/&gt; elements, each specifying a JID to accept/reject. To accept (or reject) a connection, the sender responds with an "iq-result", wrapping each JID in either an &lt;item type="connection" action="accept"/&gt; or &lt;item type="connection" action="reject"/&gt;.</p>
@ -499,7 +499,7 @@ confirm: SID00001234
<item type='connection' action='accept'>receiver@domain/res</item> <item type='connection' action='accept'>receiver@domain/res</item>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<example caption='Confirmation result (reject)'><![CDATA[ <example caption='Confirmation result (reject)'><![CDATA[
<iq id='JOBS5' type='result' to='jobs.domain'> <iq id='JOBS5' type='result' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
@ -508,7 +508,7 @@ confirm: SID00001234
<item type='connection' action='reject'>receiver@domain/res</item> <item type='connection' action='reject'>receiver@domain/res</item>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p> <p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p>
</section3> </section3>
@ -523,7 +523,7 @@ confirm: SID00001234
<item type='connection' action='drop'>receiver@domain/res</item> <item type='connection' action='drop'>receiver@domain/res</item>
</session> </session>
</iq> </iq>
]]></example> ]]></example>
<p>If the connection is successfully dropped, the service returns an "iq-result":</p> <p>If the connection is successfully dropped, the service returns an "iq-result":</p>
@ -533,7 +533,7 @@ confirm: SID00001234
status='active' status='active'
id='01234567'/> id='01234567'/>
</iq> </iq>
]]></example> ]]></example>
<p>The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).</p> <p>The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).</p>
</section3> </section3>
@ -553,14 +553,14 @@ confirm: SID00001234
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
action='delete'/> action='delete'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Delete result'><![CDATA[ <example caption='Delete result'><![CDATA[
<iq id='JOBS50' type='result' to='sender@domain/res' from='jobs.domain'> <iq id='JOBS50' type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' <session xmlns='http://jabber.org/protocol/jobs'
status='closed' status='closed'
id='01234567'/> id='01234567'/>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Being Notified about Events'> <section2 topic='Being Notified about Events'>
@ -576,7 +576,7 @@ confirm: SID00001234
<item type='connection' action='accept'/> <item type='connection' action='accept'/>
</session> </session>
</message> </message>
]]></example> ]]></example>
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p> <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3> </section3>
@ -592,7 +592,7 @@ confirm: SID00001234
<item type='connection' action='reject'/> <item type='connection' action='reject'/>
</session> </session>
</message> </message>
]]></example> ]]></example>
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p> <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3> </section3>
@ -608,7 +608,7 @@ confirm: SID00001234
<item type='connection' action='drop'/> <item type='connection' action='drop'/>
</session> </session>
</message> </message>
]]></example> ]]></example>
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p> <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3> </section3>
@ -624,7 +624,7 @@ confirm: SID00001234
<item type='status' action='delete'/> <item type='status' action='delete'/>
</session> </session>
</message> </message>
]]></example> ]]></example>
<example caption='"Session Deleted (timed out)" message'><![CDATA[ <example caption='"Session Deleted (timed out)" message'><![CDATA[
<message to='sender@domain/res' from='jobs.domain'> <message to='sender@domain/res' from='jobs.domain'>
@ -635,7 +635,7 @@ confirm: SID00001234
<item type='status' action='expire'/> <item type='status' action='expire'/>
</session> </session>
</message> </message>
]]></example> ]]></example>
<p>The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.</p> <p>The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.</p>
</section3> </section3>
@ -676,7 +676,7 @@ confirm: SID00001234
max CDATA #REQUIRED max CDATA #REQUIRED
min CDATA #REQUIRED min CDATA #REQUIRED
> >
]]></code> ]]></code>
</section3> </section3>
<section3 topic='&lt;session/&gt; Element'> <section3 topic='&lt;session/&gt; Element'>
<p>The &lt;session/&gt; element is the core element to the protocol. This element provides both information about a session and the action applied to it. It has a large number of attributes, and contains zero or more &lt;item/&gt; elements, zero or more &lt;connect/&gt; elements, and zero or three &lt;limit/&gt; elements. It may also contain elements governed by other namespaces.</p> <p>The &lt;session/&gt; element is the core element to the protocol. This element provides both information about a session and the action applied to it. It has a large number of attributes, and contains zero or more &lt;item/&gt; elements, zero or more &lt;connect/&gt; elements, and zero or three &lt;limit/&gt; elements. It may also contain elements governed by other namespaces.</p>
@ -1009,7 +1009,7 @@ SP := <US-ASCII SP, space (32)>
CR := <US-ASCII CR, carriage return (13)> CR := <US-ASCII CR, carriage return (13)>
LF := <US-ASCII LF, linefeed (10)> LF := <US-ASCII LF, linefeed (10)>
BINDATA := <Arbitrary Binary Data> BINDATA := <Arbitrary Binary Data>
]]></code></section3> ]]></code></section3>
<section3 topic='State Details'> <section3 topic='State Details'>
<table caption='"init" details'> <table caption='"init" details'>
<tr> <tr>

24
xep-0047.xml
View File

@ -133,14 +133,14 @@
sid='i781hf64' sid='i781hf64'
stanza='iq'/> stanza='iq'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the responder wishes to proceed with the IBB session, it returns an IQ-result to the initiator.</p> <p>If the responder wishes to proceed with the IBB session, it returns an IQ-result to the initiator.</p>
<example caption='Responder accepts session'><![CDATA[ <example caption='Responder accepts session'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
id='jn3h8g65' id='jn3h8g65'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>If the responder does not support IBB, it returns a &unavailable; or &feature; error.</p> <p>If the responder does not support IBB, it returns a &unavailable; or &feature; error.</p>
<example caption='Responder does not support IBB'><![CDATA[ <example caption='Responder does not support IBB'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
@ -151,7 +151,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the responder supports IBB but would prefer a smaller block-size, it returns a &constraint; error.</p> <p>If the responder supports IBB but would prefer a smaller block-size, it returns a &constraint; error.</p>
<example caption='Responder prefers smaller chunks'><![CDATA[ <example caption='Responder prefers smaller chunks'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
@ -162,7 +162,7 @@
<resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the responder supports IBB but does not wish to proceed with the session, it returns a &notacceptable; error.</p> <p>If the responder supports IBB but does not wish to proceed with the session, it returns a &notacceptable; error.</p>
<example caption='Responder does not wish to proceed'><![CDATA[ <example caption='Responder does not wish to proceed'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
@ -173,7 +173,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Sending Data' anchor='send'> <section2 topic='Sending Data' anchor='send'>
@ -192,7 +192,7 @@
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data> </data>
</iq> </iq>
]]></example> ]]></example>
<p>Each chunk of data is included as the XML character data of the &lt;data/&gt; element after being encoded as Base64 as specified in Section 4 of &rfc4648;. Each block MUST be a valid base64 block with padding at the end if needed.</p> <p>Each chunk of data is included as the XML character data of the &lt;data/&gt; element after being encoded as Base64 as specified in Section 4 of &rfc4648;. Each block MUST be a valid base64 block with padding at the end if needed.</p>
<p>The &lt;data/&gt; element MUST possess a 'seq' attribute; this is a 16-bit unsigned integer that acts as a counter for data chunks sent in a particular direction within this session. The 'seq' value starts at 0 (zero) for each sender and MUST be incremented for each packet sent by that entity. Thus, the second chunk sent has a 'seq' value of 1, the third chunk has a 'seq' value of 2, and so on. The counter loops at maximum, so that after value 65535 (2<span class='super'>15</span> - 1) the 'seq' MUST start again at 0.</p> <p>The &lt;data/&gt; element MUST possess a 'seq' attribute; this is a 16-bit unsigned integer that acts as a counter for data chunks sent in a particular direction within this session. The 'seq' value starts at 0 (zero) for each sender and MUST be incremented for each packet sent by that entity. Thus, the second chunk sent has a 'seq' value of 1, the third chunk has a 'seq' value of 2, and so on. The counter loops at maximum, so that after value 65535 (2<span class='super'>15</span> - 1) the 'seq' MUST start again at 0.</p>
<p>The &lt;data/&gt; element MUST also possess a 'sid' attribute that ties the data chunk to this particular IBB session.</p> <p>The &lt;data/&gt; element MUST also possess a 'sid' attribute that ties the data chunk to this particular IBB session.</p>
@ -202,7 +202,7 @@
id='kr91n475' id='kr91n475'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling.</p> <p>The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling.</p>
<p>It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error:</p> <p>It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error:</p>
<ol> <ol>
@ -229,14 +229,14 @@
type='set'> type='set'>
<close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/> <close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/>
</iq> </iq>
]]></example> ]]></example>
<p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original &lt;close/&gt; element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).</p> <p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original &lt;close/&gt; element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).</p>
<example caption='Success response'><![CDATA[ <example caption='Success response'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
id='us71g45j' id='us71g45j'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an &notfound; error.</p> <p>It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an &notfound; error.</p>
<example caption='Recipient does not know about the IBB session'><![CDATA[ <example caption='Recipient does not know about the IBB session'><![CDATA[
<iq type='error' <iq type='error'
@ -247,7 +247,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>In either case, both parties MUST consider the bytestream to be closed.</p> <p>In either case, both parties MUST consider the bytestream to be closed.</p>
</section2> </section2>
@ -271,7 +271,7 @@
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data> </data>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Usage Guidelines' anchor='usage'> <section1 topic='Usage Guidelines' anchor='usage'>
@ -362,7 +362,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

16
xep-0048.xml
View File

@ -120,7 +120,7 @@
<nick>Puck</nick> <nick>Puck</nick>
</conference> </conference>
</storage> </storage>
]]></example> ]]></example>
<p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p> <p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p>
<p>Note: A bookmark set may contain any number of conference rooms.</p> <p>Note: A bookmark set may contain any number of conference rooms.</p>
</section2> </section2>
@ -152,7 +152,7 @@
<url name='Complete Works of Shakespeare' <url name='Complete Works of Shakespeare'
url='http://the-tech.mit.edu/Shakespeare/'/> url='http://the-tech.mit.edu/Shakespeare/'/>
</storage> </storage>
]]></example> ]]></example>
<p>This bookmark would be displayed in the client as 'Complete Works of Shakespeare' and would take the user to &lt;<link url='http://the-tech.mit.edu/Shakespeare/'>http://the-tech.mit.edu/Shakespeare/</link>&gt; when selected.</p> <p>This bookmark would be displayed in the client as 'Complete Works of Shakespeare' and would take the user to &lt;<link url='http://the-tech.mit.edu/Shakespeare/'>http://the-tech.mit.edu/Shakespeare/</link>&gt; when selected.</p>
<p>Note: A bookmark set can contain any number of URLs.</p> <p>Note: A bookmark set can contain any number of URLs.</p>
</section2> </section2>
@ -191,10 +191,10 @@
</publish-options> </publish-options>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server acknowledges successful storage'><![CDATA[ <example caption='Server acknowledges successful storage'><![CDATA[
<iq to='juliet@capulet.lit/balcony' type='result' id='pip1'/> <iq to='juliet@capulet.lit/balcony' type='result' id='pip1'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Receiving Notifications' anchor='storage-pubsub-notify'> <section2 topic='Receiving Notifications' anchor='storage-pubsub-notify'>
<p>The stored data is automatically pushed to all of the user's connected resources.</p> <p>The stored data is automatically pushed to all of the user's connected resources.</p>
@ -236,7 +236,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving Data' anchor='storage-pubsub-retrieve'> <section2 topic='Retrieving Data' anchor='storage-pubsub-retrieve'>
<p>In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in <cite>XEP-0060</cite>.</p> <p>In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in <cite>XEP-0060</cite>.</p>
@ -246,7 +246,7 @@
<items node='storage:bookmarks'/> <items node='storage:bookmarks'/>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server returns all items'><![CDATA[ <example caption='Server returns all items'><![CDATA[
<iq type='result' <iq type='result'
to='juliet@capulet.lit/randomID' to='juliet@capulet.lit/randomID'
@ -265,7 +265,7 @@
</items> </items>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -338,7 +338,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='Author Note' anchor='authornote'>

12
xep-0049.xml
View File

@ -112,7 +112,7 @@ SERVER:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1001"/> id="1001"/>
]]></example> ]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[ <example caption='Client Retrieves Private Data'><![CDATA[
CLIENT: CLIENT:
@ -133,7 +133,7 @@ SERVER:
</exodus> </exodus>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If a user attempts to get or set jabber:iq:private data that belongs to another user, the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable).</p> <p>If a user attempts to get or set jabber:iq:private data that belongs to another user, the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable).</p>
<example caption='User Attempts to Get or Set Data for Another User'><![CDATA[ <example caption='User Attempts to Get or Set Data for Another User'><![CDATA[
@ -161,7 +161,7 @@ SERVER:
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If a user attempts to perform an IQ get without providing a child element, the server SHOULD return a "Bad Format" error (however, some existing implementations return a "Not Acceptable" error in such circumstances):</p> <p>If a user attempts to perform an IQ get without providing a child element, the server SHOULD return a "Bad Format" error (however, some existing implementations return a "Not Acceptable" error in such circumstances):</p>
<example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[ <example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[
CLIENT: CLIENT:
@ -177,7 +177,7 @@ SERVER:
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. Such behavior is OPTIONAL, but may be encountered by clients when interacting with some existing server implementations.</p> <p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. Such behavior is OPTIONAL, but may be encountered by clients when interacting with some existing server implementations.</p>
<example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[ <example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[
CLIENT: CLIENT:
@ -201,7 +201,7 @@ SERVER (optional error):
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Error Conditions'> <section1 topic='Error Conditions'>
@ -247,6 +247,6 @@ SERVER (optional error):
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

56
xep-0050.xml
View File

@ -169,7 +169,7 @@
from='requester@domain'> from='requester@domain'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Disco result for information'><![CDATA[ <example caption='Disco result for information'><![CDATA[
<iq type='result' <iq type='result'
from='responder@domain' from='responder@domain'
@ -180,7 +180,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving the Command List' anchor='retrieve'> <section2 topic='Retrieving the Command List' anchor='retrieve'>
<p>To find what commands an entity provides, the requester uses Service Discovery. Each command is a node of the responder, under the fixed node "http://jabber.org/protocol/commands" (for which the service discovery identity category is "automation" and type is "command-list"). Use of a fixed node for all commands of an entity allows for immediate retrieval of commands.</p> <p>To find what commands an entity provides, the requester uses Service Discovery. Each command is a node of the responder, under the fixed node "http://jabber.org/protocol/commands" (for which the service discovery identity category is "automation" and type is "command-list"). Use of a fixed node for all commands of an entity allows for immediate retrieval of commands.</p>
@ -193,7 +193,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/commands'/> node='http://jabber.org/protocol/commands'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Disco result for items'><![CDATA[ <example caption='Disco result for items'><![CDATA[
<iq type='result' <iq type='result'
to='requester@domain' to='requester@domain'
@ -220,7 +220,7 @@
name='Restart Service'/> name='Restart Service'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The result can then be used by the client to populate a menu, a dialog of buttons, or whatever is appropriate to the current user interface. The responder is not required to send the same list of commands to all requesters.</p> <p>The result can then be used by the client to populate a menu, a dialog of buttons, or whatever is appropriate to the current user interface. The responder is not required to send the same list of commands to all requesters.</p>
<p>If additional information about a command is desired, the requester queries for disco information on the command node:</p> <p>If additional information about a command is desired, the requester queries for disco information on the command node:</p>
<example caption='Disco request for command information'><![CDATA[ <example caption='Disco request for command information'><![CDATA[
@ -230,7 +230,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='config'/> node='config'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Disco result for command information'><![CDATA[ <example caption='Disco result for command information'><![CDATA[
<iq type='result' <iq type='result'
to='requester@domain' to='requester@domain'
@ -244,7 +244,7 @@
<feature var='jabber:x:data'/> <feature var='jabber:x:data'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>A responder MUST at least provide &lt;identity category='automation' type='command-node'/&gt; and &lt;feature var='http://jabber.org/protocol/commands'/&gt;, and SHOULD include &lt;feature var='jabber:x:data'/&gt;. It is not required to support additional information about a command. If the command is not available to the requester, the responder SHOULD respond with a 403 "Forbidden" error.</p> <p>A responder MUST at least provide &lt;identity category='automation' type='command-node'/&gt; and &lt;feature var='http://jabber.org/protocol/commands'/&gt;, and SHOULD include &lt;feature var='jabber:x:data'/&gt;. It is not required to support additional information about a command. If the command is not available to the requester, the responder SHOULD respond with a 403 "Forbidden" error.</p>
</section2> </section2>
<section2 topic='Announcing the Command List' anchor='announce'> <section2 topic='Announcing the Command List' anchor='announce'>
@ -274,7 +274,7 @@
name='Restart Service'/> name='Restart Service'/>
</query> </query>
</message> </message>
]]></example> ]]></example>
<p>The only portion required is &lt;query xmlns='http://jabber.org/protocol/disco#items'/&gt;. Any other information (such as the &lt;subject/&gt; in the foregoing example) is OPTIONAL.</p> <p>The only portion required is &lt;query xmlns='http://jabber.org/protocol/disco#items'/&gt;. Any other information (such as the &lt;subject/&gt; in the foregoing example) is OPTIONAL.</p>
</section2> </section2>
<section2 topic='Executing Commands' anchor='execute'> <section2 topic='Executing Commands' anchor='execute'>
@ -286,7 +286,7 @@
node='list' node='list'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<p>The requester MAY include the "action='execute'", although this is implied.</p> <p>The requester MAY include the "action='execute'", although this is implied.</p>
<p>If the command does not require any user interaction (returns results only), the responder sends a packet similar to the following:</p> <p>If the command does not require any user interaction (returns results only), the responder sends a packet similar to the following:</p>
<example caption="Execute command result"><![CDATA[ <example caption="Execute command result"><![CDATA[
@ -328,7 +328,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<p>The above example shows the command execution resulting in a "jabber:x:data" form. It is also possible that one or more URLs (specified via &xep0066;) could be returned.</p> <p>The above example shows the command execution resulting in a "jabber:x:data" form. It is also possible that one or more URLs (specified via &xep0066;) could be returned.</p>
<section3 topic='Multiple Stages' anchor='execute-multiple'> <section3 topic='Multiple Stages' anchor='execute-multiple'>
@ -339,7 +339,7 @@
node='config' node='config'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Execute command result (stage 1)'><![CDATA[ <example caption='Execute command result (stage 1)'><![CDATA[
<iq type='result' from='responder@domain' to='requester@domain' id='exec1'> <iq type='result' from='responder@domain' to='requester@domain' id='exec1'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -362,7 +362,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The &lt;command/&gt; SHOULD include an &lt;actions/&gt; element, which specifies the details of what the allowed actions are for this stage of execution. Each element within &lt;action/&gt; matches a possible value for the &lt;command/&gt; element's "action" attribute. The "execute" attribute defines which of the included actions is considered the equivalent to "execute" for this stage. In the above example, the only allowed action is to progress to the next stage, which is also the default.</p> <p>The &lt;command/&gt; SHOULD include an &lt;actions/&gt; element, which specifies the details of what the allowed actions are for this stage of execution. Each element within &lt;action/&gt; matches a possible value for the &lt;command/&gt; element's "action" attribute. The "execute" attribute defines which of the included actions is considered the equivalent to "execute" for this stage. In the above example, the only allowed action is to progress to the next stage, which is also the default.</p>
<p>The requester then submits the form, maintaining the command node and sessionid:</p> <p>The requester then submits the form, maintaining the command node and sessionid:</p>
<example caption='Execute command request (stage 2)'><![CDATA[ <example caption='Execute command request (stage 2)'><![CDATA[
@ -377,7 +377,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The responder then provides the next stage's form in the result <note>Note that the second stage can be reverted to the first stage or completed (signaled by the inclusion of the &lt;prev/&gt; and &lt;complete/&gt; elements), and that the default action is to complete execution (signaled by the "execute" attribute's value of "complete").</note>:</p> <p>The responder then provides the next stage's form in the result <note>Note that the second stage can be reverted to the first stage or completed (signaled by the inclusion of the &lt;prev/&gt; and &lt;complete/&gt; elements), and that the default action is to complete execution (signaled by the "execute" attribute's value of "complete").</note>:</p>
<example caption='Execute command result (stage 2)'><![CDATA[ <example caption='Execute command result (stage 2)'><![CDATA[
<iq type='result' from='responder@domain' to='requester@domain' id='exec2'> <iq type='result' from='responder@domain' to='requester@domain' id='exec2'>
@ -410,7 +410,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The requester then submits the second stage's form, again maintaining the node and sessionid:</p> <p>The requester then submits the second stage's form, again maintaining the node and sessionid:</p>
<example caption='Execute command request (stage 3)'><![CDATA[ <example caption='Execute command request (stage 3)'><![CDATA[
<iq type='set' to='responder@domain' id='exec3'> <iq type='set' to='responder@domain' id='exec3'>
@ -427,7 +427,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Execute command result (stage 3)'><![CDATA[ <example caption='Execute command result (stage 3)'><![CDATA[
<iq type='result' from='responder@domain' to='requester@domain' id='exec3'> <iq type='result' from='responder@domain' to='requester@domain' id='exec3'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -437,7 +437,7 @@
<note type='info'>Service 'httpd' has been configured.</note> <note type='info'>Service 'httpd' has been configured.</note>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>If the requester wishes to revert to the previous stage, it sends an &IQ; with the command's node and sessionid, and "action='prev'":</p> <p>If the requester wishes to revert to the previous stage, it sends an &IQ; with the command's node and sessionid, and "action='prev'":</p>
<example caption='Execute command request (revert from stage 2 to stage 1)'><![CDATA[ <example caption='Execute command request (revert from stage 2 to stage 1)'><![CDATA[
<iq type='set' to='responder@domain' id='exec2'> <iq type='set' to='responder@domain' id='exec2'>
@ -446,7 +446,7 @@
node='config' node='config'
action='prev'/> action='prev'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the responder accepts this, it responds with the previous stage's command <note>The responder MAY present "remembered" field values, but doing so is OPTIONAL.</note>:</p> <p>If the responder accepts this, it responds with the previous stage's command <note>The responder MAY present "remembered" field values, but doing so is OPTIONAL.</note>:</p>
<example caption='Execute command result (revert from stage 2 to stage 1)'><![CDATA[ <example caption='Execute command result (revert from stage 2 to stage 1)'><![CDATA[
<iq type='result' from='responder@domain' to='requester@domain' id='exec2'> <iq type='result' from='responder@domain' to='requester@domain' id='exec2'>
@ -471,7 +471,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Canceling' anchor='cancel'> <section3 topic='Canceling' anchor='cancel'>
<p>In the case where a command has multiple stages, the requester may wish to cancel at some point. To cancel, the requester sends the continuing command request with an "action='cancel'":</p> <p>In the case where a command has multiple stages, the requester may wish to cancel at some point. To cancel, the requester sends the continuing command request with an "action='cancel'":</p>
@ -482,7 +482,7 @@
node='config' node='config'
action='cancel'/> action='cancel'/>
</iq> </iq>
]]></example> ]]></example>
<p>This enables the responder to free any resources allocated during the process. The responder MUST reply with the success of the command:</p> <p>This enables the responder to free any resources allocated during the process. The responder MUST reply with the success of the command:</p>
<example caption='Execute command result (stage 2; canceled)'><![CDATA[ <example caption='Execute command result (stage 2; canceled)'><![CDATA[
<iq type='result' from='responder@domain' to='requester@domain' id='exec3'> <iq type='result' from='responder@domain' to='requester@domain' id='exec3'>
@ -491,7 +491,7 @@
node='config' node='config'
status='canceled'/> status='canceled'/>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -552,7 +552,7 @@
node='list' node='list'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Execute command result (with language/locale)"><![CDATA[ <example caption="Execute command result (with language/locale)"><![CDATA[
<iq type='result' <iq type='result'
from='responder@domain' from='responder@domain'
@ -596,7 +596,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Within the "http://jabber.org/protocol/commands" schema, the language/locale applies only to the human-readable character data for &lt;info/&gt; elements. It SHOULD also apply to all payload elements, appropriate to their respective specifications.</p> <p>Within the "http://jabber.org/protocol/commands" schema, the language/locale applies only to the human-readable character data for &lt;info/&gt; elements. It SHOULD also apply to all payload elements, appropriate to their respective specifications.</p>
<p>Responders MUST take this into consideration, and properly account for the language/locale settings within payloads. If the responder cannot accomodate the requested language/locale, it SHOULD respond with a &lt;bad-request/&gt; (&lt;bad-locale/&gt;) error condition.</p> <p>Responders MUST take this into consideration, and properly account for the language/locale settings within payloads. If the responder cannot accomodate the requested language/locale, it SHOULD respond with a &lt;bad-request/&gt; (&lt;bad-locale/&gt;) error condition.</p>
<example caption='Execute command request (with language/locale)'><![CDATA[ <example caption='Execute command request (with language/locale)'><![CDATA[
@ -605,7 +605,7 @@
node='list' node='list'
action='execute'/> action='execute'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Execute command failed result (with language/locale)'><![CDATA[ <example caption='Execute command failed result (with language/locale)'><![CDATA[
<iq type='error' from='responder@domain' to='requester@domain/resource' id='exec1'> <iq type='error' from='responder@domain' to='requester@domain/resource' id='exec1'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -617,7 +617,7 @@
<bad-locale xmlns='http://jabber.org/protocol/commands'/> <bad-locale xmlns='http://jabber.org/protocol/commands'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Formal Description' anchor='desc'> <section1 topic='Formal Description' anchor='desc'>
@ -831,7 +831,7 @@
<doc>XEP-0050</doc> <doc>XEP-0050</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'> <section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'>
<p>The XMPP Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.</p> <p>The XMPP Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.</p>
@ -841,12 +841,12 @@
<p>The "command" querytype is defined herein for interaction with entities that support the ad-hoc command protocol, with keys of "action" and "node".</p> <p>The "command" querytype is defined herein for interaction with entities that support the ad-hoc command protocol, with keys of "action" and "node".</p>
<example caption='Command Action: IRI/URI'><![CDATA[ <example caption='Command Action: IRI/URI'><![CDATA[
xmpp:montague.net?command;node=stats xmpp:montague.net?command;node=stats
]]></example> ]]></example>
<example caption='Command Action: Resulting Stanza'><![CDATA[ <example caption='Command Action: Resulting Stanza'><![CDATA[
<iq to='montague.net' type='set'> <iq to='montague.net' type='set'>
<command xmlns='http://jabber.org/protocol/commands' node='stats'/> <command xmlns='http://jabber.org/protocol/commands' node='stats'/>
</iq> </iq>
]]></example> ]]></example>
<p>The following submission registers the "command" querytype.</p> <p>The following submission registers the "command" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -887,7 +887,7 @@ xmpp:montague.net?command;node=stats
</key> </key>
</keys> </keys>
</querytype> </querytype>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -994,7 +994,7 @@ xmpp:montague.net?command;node=stats
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>

8
xep-0051.xml
View File

@ -80,7 +80,7 @@
<server>123.123.123.122</server> <server>123.123.123.122</server>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server tells client to connect to a different server in the cluster (by domain name)'><![CDATA[ <example caption='Server tells client to connect to a different server in the cluster (by domain name)'><![CDATA[
<iq type='set' from='jabber.org' to='user@jabber.org'> <iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'> <query xmlns='urn:xmpp:cxfr'>
@ -88,7 +88,7 @@
<server>server2.jabber.org</server> <server>server2.jabber.org</server>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server tells client to connect to a different server in the cluster (using a different port number)'><![CDATA[ <example caption='Server tells client to connect to a different server in the cluster (using a different port number)'><![CDATA[
<iq type='set' from='jabber.org' to='user@jabber.org'> <iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'> <query xmlns='urn:xmpp:cxfr'>
@ -96,7 +96,7 @@
<server>server3.jabber.org:6222</server> <server>server3.jabber.org:6222</server>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server tells client to simply reconnect'><![CDATA[ <example caption='Server tells client to simply reconnect'><![CDATA[
<iq type='set' from='jabber.org' to='user@jabber.org'> <iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'> <query xmlns='urn:xmpp:cxfr'>
@ -104,7 +104,7 @@
<server>jabber.org</server> <server>jabber.org</server>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>To follow.</p> <p>To follow.</p>

2
xep-0052.xml
View File

@ -289,7 +289,7 @@
<!ATTLIST range <!ATTLIST range
length CDATA #OPTIONAL length CDATA #OPTIONAL
offset CDATA #OPTIONAL > offset CDATA #OPTIONAL >
]]></code> ]]></code>
</section2> </section2>
<section2 topic='&lt;file/&gt; Element'> <section2 topic='&lt;file/&gt; Element'>
<p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt; (&xep0020;) elements.</p> <p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt; (&xep0020;) elements.</p>

32
xep-0054.xml
View File

@ -69,7 +69,7 @@
type='get'> type='get'>
<vCard xmlns='vcard-temp'/> <vCard xmlns='vcard-temp'/>
</iq> </iq>
]]></example> ]]></example>
<p>If a vCard exists for the user, the server MUST return in an IQ-result:</p> <p>If a vCard exists for the user, the server MUST return in an IQ-result:</p>
<example caption="Server Returns vCard"><![CDATA[ <example caption="Server Returns vCard"><![CDATA[
<iq id='v1' <iq id='v1'
@ -123,7 +123,7 @@
</DESC> </DESC>
</vCard> </vCard>
</iq> </iq>
]]></example> ]]></example>
<p>If no vCard exists, the server MUST return a stanza error (which SHOULD be &notfound;) or an IQ-result containing an empty &lt;vCard/&gt; element.</p> <p>If no vCard exists, the server MUST return a stanza error (which SHOULD be &notfound;) or an IQ-result containing an empty &lt;vCard/&gt; element.</p>
<example caption="No vCard (item-not-found)"><![CDATA[ <example caption="No vCard (item-not-found)"><![CDATA[
<iq id='v1' <iq id='v1'
@ -134,14 +134,14 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption="No vCard (empty element)"><![CDATA[ <example caption="No vCard (empty element)"><![CDATA[
<iq id='v1' <iq id='v1'
to='stpeter@jabber.org/roundabout' to='stpeter@jabber.org/roundabout'
type='result'> type='result'>
<vCard xmlns='vcard-temp'/> <vCard xmlns='vcard-temp'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Updating One&apos;s vCard"> <section2 topic="Updating One&apos;s vCard">
<p>A user may publish or update his or her vCard by sending an IQ of type "set" with no 'to' address, following the format in the previous use case.</p> <p>A user may publish or update his or her vCard by sending an IQ of type "set" with no 'to' address, following the format in the previous use case.</p>
@ -194,13 +194,13 @@
</DESC> </DESC>
</vCard> </vCard>
</iq> </iq>
]]></example> ]]></example>
<p>The server then returns an IQ-result (or an IQ-error).</p> <p>The server then returns an IQ-result (or an IQ-error).</p>
<example caption="Server Returns Success"><![CDATA[ <example caption="Server Returns Success"><![CDATA[
<iq id='v2' <iq id='v2'
to='stpeter@jabber.org/roundabout' to='stpeter@jabber.org/roundabout'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>Notice that the previous IQ-set included only one changed element (the &lt;DESC/&gt; element). Currently there is no method for partial updates of a vCard, and the entire vCard must be sent to the server in order to update any part of the vCard.</p> <p>Notice that the previous IQ-set included only one changed element (the &lt;DESC/&gt; element). Currently there is no method for partial updates of a vCard, and the entire vCard must be sent to the server in order to update any part of the vCard.</p>
<p>If a user attempts to perform an IQ set on another user's vCard (i.e., by setting a 'to' address to a JID other than the sending user's bare JID), the server MUST return a stanza error, which SHOULD be &forbidden; or &notallowed;.</p> <p>If a user attempts to perform an IQ set on another user's vCard (i.e., by setting a 'to' address to a JID other than the sending user's bare JID), the server MUST return a stanza error, which SHOULD be &forbidden; or &notallowed;.</p>
<example caption="Entity Attempts to Modify Another Entity&apos;s vCard"><![CDATA[ <example caption="Entity Attempts to Modify Another Entity&apos;s vCard"><![CDATA[
@ -211,7 +211,7 @@
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Viewing Another User&apos;s vCard"> <section2 topic="Viewing Another User&apos;s vCard">
<p>A user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID.</p> <p>A user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID.</p>
@ -222,7 +222,7 @@
type='get'> type='get'>
<vCard xmlns='vcard-temp'/> <vCard xmlns='vcard-temp'/>
</iq> </iq>
]]></example> ]]></example>
<p>In accordance with &xmppcore;, a compliant server MUST respond on behalf of the requestor and not forward the IQ to the requestee's connected resource.</p> <p>In accordance with &xmppcore;, a compliant server MUST respond on behalf of the requestor and not forward the IQ to the requestee's connected resource.</p>
<example caption="Receiving Another User's vCard"><![CDATA[ <example caption="Receiving Another User's vCard"><![CDATA[
<iq from='jer@jabber.org' <iq from='jer@jabber.org'
@ -241,7 +241,7 @@
<JABBERID>jer@jabber.org</JABBERID> <JABBERID>jer@jabber.org</JABBERID>
</vCard> </vCard>
</iq> </iq>
]]></example> ]]></example>
<p>If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either &unavailable; or &notfound; (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks).</p> <p>If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either &unavailable; or &notfound; (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks).</p>
<example caption="No vCard"><![CDATA[ <example caption="No vCard"><![CDATA[
<iq id='v3' <iq id='v3'
@ -252,7 +252,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The use of vCards is not limited to accounts associated with human users. For example, an XMPP server could itself have a vCard that defines the server's hosting organization, physical location, and relevant contact addresses.</p> <p>Note: The use of vCards is not limited to accounts associated with human users. For example, an XMPP server could itself have a vCard that defines the server's hosting organization, physical location, and relevant contact addresses.</p>
</section2> </section2>
</section1> </section1>
@ -265,7 +265,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery Information Response"><![CDATA[ <example caption="Service Discovery Information Response"><![CDATA[
<iq type='result' <iq type='result'
from='capulet.lit' from='capulet.lit'
@ -277,7 +277,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>This information can also be encapsulated via &xep0115; for entities who share presence.</p> <p>This information can also be encapsulated via &xep0115; for entities who share presence.</p>
</section1> </section1>
@ -296,12 +296,12 @@
<p>The "vcard" querytype is registered as a vCard-related action.</p> <p>The "vcard" querytype is registered as a vCard-related action.</p>
<example caption='vCard Action: IRI/URI'><![CDATA[ <example caption='vCard Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?vcard xmpp:romeo@montague.net?vcard
]]></example> ]]></example>
<example caption='vCard Action: Resulting Stanza'><![CDATA[ <example caption='vCard Action: Resulting Stanza'><![CDATA[
<iq to='romeo@montague.net' type='get'> <iq to='romeo@montague.net' type='get'>
<vCard xmlns='vcard-temp'/> <vCard xmlns='vcard-temp'/>
</iq> </iq>
]]></example> ]]></example>
<p>The following submission registers the "vcard" querytype.</p> <p>The following submission registers the "vcard" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -310,7 +310,7 @@ xmpp:romeo@montague.net?vcard
<desc>enables retrieval of an entity's vCard data</desc> <desc>enables retrieval of an entity's vCard data</desc>
<doc>XEP-0054</doc> <doc>XEP-0054</doc>
</querytype> </querytype>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -643,6 +643,6 @@ PARTICULAR PURPOSE.
<!ELEMENT EXTVAL (#PCDATA)> <!ELEMENT EXTVAL (#PCDATA)>
<!-- ==== --> <!-- ==== -->
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

24
xep-0055.xml
View File

@ -70,7 +70,7 @@
xml:lang='en'> xml:lang='en'>
<query xmlns='jabber:iq:search'/> <query xmlns='jabber:iq:search'/>
</iq> </iq>
]]></example> ]]></example>
<p>The service MUST then return the possible search fields to the user, and MAY include instructions:</p> <p>The service MUST then return the possible search fields to the user, and MAY include instructions:</p>
<example caption="Receiving Search Fields"><![CDATA[ <example caption="Receiving Search Fields"><![CDATA[
<iq type='result' <iq type='result'
@ -89,7 +89,7 @@
<email/> <email/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The user MAY then submit a search request, specifying values for any desired fields:</p> <p>The user MAY then submit a search request, specifying values for any desired fields:</p>
<example caption="Submitting a Search Request"><![CDATA[ <example caption="Submitting a Search Request"><![CDATA[
<iq type='set' <iq type='set'
@ -101,7 +101,7 @@
<last>Capulet</last> <last>Capulet</last>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The service SHOULD then return a list of search results that match the values provided:</p> <p>The service SHOULD then return a list of search results that match the values provided:</p>
<example caption="Receiving Search Results"><![CDATA[ <example caption="Receiving Search Results"><![CDATA[
<iq type='result' <iq type='result'
@ -124,7 +124,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If there are no matching directory entries, the service MUST return an empty &lt;query/&gt; element:</p> <p>If there are no matching directory entries, the service MUST return an empty &lt;query/&gt; element:</p>
<example caption="Service Informs User that No Records Match"><![CDATA[ <example caption="Service Informs User that No Records Match"><![CDATA[
<iq type='result' <iq type='result'
@ -134,7 +134,7 @@
xml:lang='en'> xml:lang='en'>
<query xmlns='jabber:iq:search'/> <query xmlns='jabber:iq:search'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Extensibility' anchor='extensibility'> <section1 topic='Extensibility' anchor='extensibility'>
@ -148,7 +148,7 @@
xml:lang='en'> xml:lang='en'>
<query xmlns='jabber:iq:search'/> <query xmlns='jabber:iq:search'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Host Returns Search Form to Entity'><![CDATA[ <example caption='Host Returns Search Form to Entity'><![CDATA[
<iq type='result' <iq type='result'
from='characters.shakespeare.lit' from='characters.shakespeare.lit'
@ -185,7 +185,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Entity Submits Search Form'><![CDATA[ <example caption='Entity Submits Search Form'><![CDATA[
<iq type='set' <iq type='set'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
@ -203,7 +203,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Returns Search Results'><![CDATA[ <example caption='Service Returns Search Results'><![CDATA[
<iq type='result' <iq type='result'
from='characters.shakespeare.lit' from='characters.shakespeare.lit'
@ -236,7 +236,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Internationalization Considerations' anchor='i18n'> <section1 topic='Internationalization Considerations' anchor='i18n'>
<p>The intent of the &lt;first/&gt; and &lt;last/&gt; elements (and associated data form fields) is that they map to given name and family name, respectively. Therefore, cultures that place the family name first and the given name second (e.g., as is done in China) would use &lt;first/&gt; for the given name and &lt;last/&gt; for the family name, NOT the other way around.</p> <p>The intent of the &lt;first/&gt; and &lt;last/&gt; elements (and associated data form fields) is that they map to given name and family name, respectively. Therefore, cultures that place the family name first and the given name second (e.g., as is done in China) would use &lt;first/&gt; for the given name and &lt;last/&gt; for the family name, NOT the other way around.</p>
@ -253,7 +253,7 @@
<last>Kong</last> <last>Kong</last>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>There are no security features or concerns related to this proposal.</p> <p>There are no security features or concerns related to this proposal.</p>
@ -290,7 +290,7 @@
type='text-single' type='text-single'
label='Email Address'/> label='Email Address'/>
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -342,6 +342,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

44
xep-0059.xml
View File

@ -145,7 +145,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The responding entity then returns the first items of the result set in order. The number of items is limited to the requested size:</p> <p>The responding entity then returns the first items of the result set in order. The number of items is limited to the requested size:</p>
<example caption='Returning a Limited Result Set'><![CDATA[ <example caption='Returning a Limited Result Set'><![CDATA[
<iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='limit1'> <iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='limit1'>
@ -165,7 +165,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Paging Forwards Through a Result Set' anchor='forwards'> <section2 topic='Paging Forwards Through a Result Set' anchor='forwards'>
<p>An entity often needs to retrieve a page of items adjacent to a page it has already received. For examples, when retrieving a complete result set in order page by page, or when a user 'scrolls' forwards one page.</p> <p>An entity often needs to retrieve a page of items adjacent to a page it has already received. For examples, when retrieving a complete result set in order page by page, or when a user 'scrolls' forwards one page.</p>
@ -188,7 +188,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Responding entity support for paging through a result set is optional. If it does support paging (not just <link url='#limit'>Limiting the Number of Items</link>), then in each page it returns, the responding entity MUST include &lt;first/&gt; and &lt;last/&gt; elements that specify the unique ID (UID) for the first and last items in the page. If there is only one item in the page, then the first and last UIDs MUST be the same. If there are no items in the page, then the &lt;first/&gt; and &lt;last/&gt; elements MUST NOT be included.</p> <p>Responding entity support for paging through a result set is optional. If it does support paging (not just <link url='#limit'>Limiting the Number of Items</link>), then in each page it returns, the responding entity MUST include &lt;first/&gt; and &lt;last/&gt; elements that specify the unique ID (UID) for the first and last items in the page. If there is only one item in the page, then the first and last UIDs MUST be the same. If there are no items in the page, then the &lt;first/&gt; and &lt;last/&gt; elements MUST NOT be included.</p>
<p>The responding entity may generate these UIDs in any way, as long as the UIDs are unique in the context of all possible members of the full result set. Each UID MAY be based on part of the content of its associated item, as shown below, or on an internal table index. Another possible method is to serialize the XML of the item and then hash it to generate the UID. Note: The requesting entity MUST treat all UIDs as opaque.</p> <p>The responding entity may generate these UIDs in any way, as long as the UIDs are unique in the context of all possible members of the full result set. Each UID MAY be based on part of the content of its associated item, as shown below, or on an internal table index. Another possible method is to serialize the XML of the item and then hash it to generate the UID. Note: The requesting entity MUST treat all UIDs as opaque.</p>
<p>The responding entity SHOULD also include the number of items in the full result set (which MAY be approximate) encapsulated in a &lt;count/&gt; element. The &lt;first/&gt; element SHOULD include an 'index' attribute. This integer specifies the position within the full set (which MAY be approximate) of the first item in the page. If that item is the first in the full set, then the index SHOULD be '0'. If the last item in the page is the last item in the full set, then the value of the &lt;first/&gt; element's 'index' attribute SHOULD be the specified count minus the number of items in the last page.</p> <p>The responding entity SHOULD also include the number of items in the full result set (which MAY be approximate) encapsulated in a &lt;count/&gt; element. The &lt;first/&gt; element SHOULD include an 'index' attribute. This integer specifies the position within the full set (which MAY be approximate) of the first item in the page. If that item is the first in the full set, then the index SHOULD be '0'. If the last item in the page is the last item in the full set, then the value of the &lt;first/&gt; element's 'index' attribute SHOULD be the specified count minus the number of items in the last page.</p>
@ -216,7 +216,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The requesting entity can then ask for the next page in the result set by including in its request the UID of the <em>last</em> item from the previous page (encapsulated in an &lt;after/&gt; element), along with the maximum number of items to return. Note: If no &lt;after/&gt; element is specified, then the UID defaults to "before the first item in the result set" (i.e., effectively an index of negative one).</p> <p>The requesting entity can then ask for the next page in the result set by including in its request the UID of the <em>last</em> item from the previous page (encapsulated in an &lt;after/&gt; element), along with the maximum number of items to return. Note: If no &lt;after/&gt; element is specified, then the UID defaults to "before the first item in the result set" (i.e., effectively an index of negative one).</p>
<example caption='Requesting the Second Page of a Result Set'><![CDATA[ <example caption='Requesting the Second Page of a Result Set'><![CDATA[
<iq type='set' from='stpeter@jabber.org/roundabout' to='users.jabber.org' id='page2'> <iq type='set' from='stpeter@jabber.org/roundabout' to='users.jabber.org' id='page2'>
@ -228,7 +228,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The <em>first</em> item in the page returned by the responding entity MUST be the item that immediately <em>follows</em> the item that the requesting entity indicated in the &lt;after/&gt; element:</p> <p>The <em>first</em> item in the page returned by the responding entity MUST be the item that immediately <em>follows</em> the item that the requesting entity indicated in the &lt;after/&gt; element:</p>
<example caption='Returning the Second Page of a Result Set'><![CDATA[ <example caption='Returning the Second Page of a Result Set'><![CDATA[
<iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='page2'> <iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='page2'>
@ -253,7 +253,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>It may sometimes be necessary to return an empty <em>page</em> to the requesting entity. For example, with dynamic result sets the responding entity MAY delete some items from the full result set between requests. Another example occurs when the requesting entity specifies "0" for the maximum number items to return (see <link url='#count'>Getting the Item Count</link>).</p> <p>It may sometimes be necessary to return an empty <em>page</em> to the requesting entity. For example, with dynamic result sets the responding entity MAY delete some items from the full result set between requests. Another example occurs when the requesting entity specifies "0" for the maximum number items to return (see <link url='#count'>Getting the Item Count</link>).</p>
<example caption='Returning an Empty Page'><![CDATA[ <example caption='Returning an Empty Page'><![CDATA[
<iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='page80'> <iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='page80'>
@ -263,7 +263,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If there are no items whatsoever in the <em>full</em> result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both <cite>XEP-0055</cite> and <cite>XEP-0030</cite>, that means the responding entity shall return an empty &QUERY; element; for <cite>XEP-0060</cite>, that means the responding entity shall return an empty &lt;pubsub/&gt; element; for <cite>XEP-0136</cite>, that means the responding entity shall return an empty &lt;list/&gt; or &lt;store/&gt; element.</p> <p>If there are no items whatsoever in the <em>full</em> result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both <cite>XEP-0055</cite> and <cite>XEP-0030</cite>, that means the responding entity shall return an empty &QUERY; element; for <cite>XEP-0060</cite>, that means the responding entity shall return an empty &lt;pubsub/&gt; element; for <cite>XEP-0136</cite>, that means the responding entity shall return an empty &lt;list/&gt; or &lt;store/&gt; element.</p>
</section2> </section2>
<section2 topic='Paging Backwards Through a Result Set' anchor='backwards'> <section2 topic='Paging Backwards Through a Result Set' anchor='backwards'>
@ -278,7 +278,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The <em>last</em> item in the page returned by the responding entity MUST be the item that immediately <em>preceeds</em> the item that the requesting entity indicated it has already received:</p> <p>The <em>last</em> item in the page returned by the responding entity MUST be the item that immediately <em>preceeds</em> the item that the requesting entity indicated it has already received:</p>
<example caption='Returning the Previous Page of a Result Set'><![CDATA[ <example caption='Returning the Previous Page of a Result Set'><![CDATA[
<iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='back1'> <iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='back1'>
@ -303,7 +303,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Page Not Found' anchor='notfound'> <section2 topic='Page Not Found' anchor='notfound'>
<p>The responding entity MUST reply with an 'item-not-found' error if <em>all</em> the following circumstances apply:</p> <p>The responding entity MUST reply with an 'item-not-found' error if <em>all</em> the following circumstances apply:</p>
@ -325,7 +325,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Requesting the Last Page in a Result Set' anchor='last'> <section2 topic='Requesting the Last Page in a Result Set' anchor='last'>
<p>The requesting entity MAY ask for the last page in a result set by including in its request an empty &lt;before/&gt; element, and the maximum number of items to return.</p> <p>The requesting entity MAY ask for the last page in a result set by including in its request an empty &lt;before/&gt; element, and the maximum number of items to return.</p>
@ -339,7 +339,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving a Page Out of Order' anchor='jump'> <section2 topic='Retrieving a Page Out of Order' anchor='jump'>
<p>The requesting entity MAY choose not to retrieve pages from the result set in order. (For example, when its user drags a user-interface slider to a radically new position within a very large result set.)</p> <p>The requesting entity MAY choose not to retrieve pages from the result set in order. (For example, when its user drags a user-interface slider to a radically new position within a very large result set.)</p>
@ -355,7 +355,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The responding entity SHOULD derive the first UID from the specified index (the method used MAY be approximate) before returning the requested result set page in the normal way. If the specified index was "0" then the responding entity SHOULD derive the UID that is the first in the full result set.</p> <p>The responding entity SHOULD derive the first UID from the specified index (the method used MAY be approximate) before returning the requested result set page in the normal way. If the specified index was "0" then the responding entity SHOULD derive the UID that is the first in the full result set.</p>
<p>Note: The 'index' attribute of the &lt;first/&gt; element MUST be the same as the index specified in the request. If the index specified by the requesting entity is greater than or equal to the number of items in the full set then the responding entity MUST return an empty page (see <link url='#forwards'>Paging Forwards Through a Result Set</link>).</p> <p>Note: The 'index' attribute of the &lt;first/&gt; element MUST be the same as the index specified in the request. If the index specified by the requesting entity is greater than or equal to the number of items in the full set then the responding entity MUST return an empty page (see <link url='#forwards'>Paging Forwards Through a Result Set</link>).</p>
<example caption='Returning a Result Page at an Index'><![CDATA[ <example caption='Returning a Result Page at an Index'><![CDATA[
@ -381,7 +381,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If it would be either impossible or exceptionally resource intensive for the responding entity to derive the first UID from the specified index with reasonable accuracy then the responding entity MAY return a &e501; error.</p> <p>If it would be either impossible or exceptionally resource intensive for the responding entity to derive the first UID from the specified index with reasonable accuracy then the responding entity MAY return a &e501; error.</p>
<example caption='Returning a Feature-not-Implemented Error'><![CDATA[ <example caption='Returning a Feature-not-Implemented Error'><![CDATA[
<iq type='error' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='index10'> <iq type='error' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='index10'>
@ -396,7 +396,7 @@
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Getting the Item Count' anchor='count'> <section2 topic='Getting the Item Count' anchor='count'>
<p>In order to get the item count of a result set without retrieving the items themselves, the requesting entity simply specifies zero for the maximum size of the result set page:</p> <p>In order to get the item count of a result set without retrieving the items themselves, the requesting entity simply specifies zero for the maximum size of the result set page:</p>
@ -409,7 +409,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The responding entity then returns the item count, which MAY be approximate rather than precise if determining the exact number of items would be resource-intensive:</p> <p>The responding entity then returns the item count, which MAY be approximate rather than precise if determining the exact number of items would be resource-intensive:</p>
<example caption='Returning the Item Count'><![CDATA[ <example caption='Returning the Item Count'><![CDATA[
<iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='count1'> <iq type='result' from='users.jabber.org' to='stpeter@jabber.org/roundabout' id='count1'>
@ -419,7 +419,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The &lt;count/&gt; element MAY be omitted, but <em>only</em> if it would be either impossible or exceptionally resource intensive to calculate reasonably accurate values.</p> <p>Note: The &lt;count/&gt; element MAY be omitted, but <em>only</em> if it would be either impossible or exceptionally resource intensive to calculate reasonably accurate values.</p>
<p>Note: If there are no items in the <em>full</em> result set then the responding entity MUST return a response that adheres to the definition of the wrapper protocol (see <link url='#forwards'>Paging Forwards Through a Result Set</link>).</p> <p>Note: If there are no items in the <em>full</em> result set then the responding entity MUST return a response that adheres to the definition of the wrapper protocol (see <link url='#forwards'>Paging Forwards Through a Result Set</link>).</p>
</section2> </section2>
@ -434,7 +434,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning a Limited Result Set'><![CDATA[ <example caption='Returning a Limited Result Set'><![CDATA[
<iq type='result' from='conference.jabber.org' to='stpeter@jabber.org/roundabout' id='ex2'> <iq type='result' from='conference.jabber.org' to='stpeter@jabber.org/roundabout' id='ex2'>
<query xmlns='http://jabber.org/protocol/disco#items'> <query xmlns='http://jabber.org/protocol/disco#items'>
@ -465,7 +465,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting a Page Beginning After the Last Item Received'><![CDATA[ <example caption='Requesting a Page Beginning After the Last Item Received'><![CDATA[
<iq type='set' from='stpeter@jabber.org/roundabout' to='conference.jabber.org' id='ex3'> <iq type='set' from='stpeter@jabber.org/roundabout' to='conference.jabber.org' id='ex3'>
<query xmlns='http://jabber.org/protocol/disco#items'> <query xmlns='http://jabber.org/protocol/disco#items'>
@ -475,7 +475,7 @@
</set> </set>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Determining Support' anchor='support'> <section1 topic='Determining Support' anchor='support'>
<p>In order for a requesting entity to determine if a responding entity supports result set management, it SHOULD send a <cite>Service Discovery</cite> information request to the responding entity:</p> <p>In order for a requesting entity to determine if a responding entity supports result set management, it SHOULD send a <cite>Service Discovery</cite> information request to the responding entity:</p>
@ -486,7 +486,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Responding entity communicates protocol support'><![CDATA[ <example caption='Responding entity communicates protocol support'><![CDATA[
<iq from='conference.jabber.org' <iq from='conference.jabber.org'
to='stpeter@jabber.org/roundabout' to='stpeter@jabber.org/roundabout'
@ -496,7 +496,7 @@
<feature var='http://jabber.org/protocol/rsm'/> <feature var='http://jabber.org/protocol/rsm'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>An entity SHOULD NOT include the result set management extensions defined in this document in its requests if it does not have positive knowledge that the responding entity supports the protocol defined herein. If the responding entity does not understand result set management, it MUST ignore such extensions.</p> <p>An entity SHOULD NOT include the result set management extensions defined in this document in its requests if it does not have positive knowledge that the responding entity supports the protocol defined herein. If the responding entity does not understand result set management, it MUST ignore such extensions.</p>
<p>Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.</p> <p>Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.</p>
</section1> </section1>
@ -553,7 +553,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Olivier Goffart, Jon Perlow, and Andrew Plotkin for their feedback.</p> <p>Thanks to Olivier Goffart, Jon Perlow, and Andrew Plotkin for their feedback.</p>

26
xep-0060.xml
View File

@ -5828,7 +5828,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<doc>XEP-0060</doc> <doc>XEP-0060</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
<p>Future submissions to the XMPP Registrar may register additional types.</p> <p>Future submissions to the XMPP Registrar may register additional types.</p>
</section2> </section2>
@ -6048,7 +6048,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<desc>Notification of subscription state changes is supported.</desc> <desc>Notification of subscription state changes is supported.</desc>
<doc>XEP-0060</doc> <doc>XEP-0060</doc>
</var> </var>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'> <section2 topic='Field Standardization' anchor='registrar-formtypes'>
@ -6085,7 +6085,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
type='text-single' type='text-single'
label='The subscription identifier associated with the subscription request'/> label='The subscription identifier associated with the subscription request'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='pubsub#subscribe_options FORM_TYPE' anchor='registrar-formtypes-subscribe'> <section3 topic='pubsub#subscribe_options FORM_TYPE' anchor='registrar-formtypes-subscribe'>
<code><![CDATA[ <code><![CDATA[
@ -6159,7 +6159,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
</option> </option>
</field> </field>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='pubsub#meta-data FORM_TYPE' anchor='registrar-formtypes-metadata'> <section3 topic='pubsub#meta-data FORM_TYPE' anchor='registrar-formtypes-metadata'>
<code><![CDATA[ <code><![CDATA[
@ -6198,7 +6198,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
type='text-single' type='text-single'
label='Payload type'/> label='Payload type'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='pubsub#node_config FORM_TYPE' anchor='registrar-formtypes-config'> <section3 topic='pubsub#node_config FORM_TYPE' anchor='registrar-formtypes-config'>
<code><![CDATA[ <code><![CDATA[
@ -6381,7 +6381,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
label='The type of node data, usually specified by label='The type of node data, usually specified by
the namespace of the payload (if any)'/> the namespace of the payload (if any)'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='pubsub#publish-options FORM_TYPE' anchor='registrar-formtypes-publish'> <section3 topic='pubsub#publish-options FORM_TYPE' anchor='registrar-formtypes-publish'>
<code><![CDATA[ <code><![CDATA[
@ -6413,7 +6413,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
</option> </option>
</field> </field>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
<section2 topic='SHIM Headers' anchor='registrar-shim'> <section2 topic='SHIM Headers' anchor='registrar-shim'>
@ -6429,7 +6429,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<desc>A subscription identifer within the pubsub protocol.</desc> <desc>A subscription identifer within the pubsub protocol.</desc>
<doc>XEP-0060</doc> <doc>XEP-0060</doc>
</header> </header>
]]></code> ]]></code>
<p>Future submissions to the XMPP Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.</p> <p>Future submissions to the XMPP Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.</p>
</section2> </section2>
<section2 topic='URI Query Types' anchor='registrar-querytypes'> <section2 topic='URI Query Types' anchor='registrar-querytypes'>
@ -6493,7 +6493,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</key> </key>
</keys> </keys>
</querytype> </querytype>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
@ -6743,7 +6743,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='http://jabber.org/protocol/pubsub#errors' anchor='schemas-error'> <section2 topic='http://jabber.org/protocol/pubsub#errors' anchor='schemas-error'>
@ -6851,7 +6851,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='http://jabber.org/protocol/pubsub#event' anchor='schemas-event'> <section2 topic='http://jabber.org/protocol/pubsub#event' anchor='schemas-event'>
@ -7017,7 +7017,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='http://jabber.org/protocol/pubsub#owner' anchor='schemas-owner'> <section2 topic='http://jabber.org/protocol/pubsub#owner' anchor='schemas-owner'>
@ -7167,7 +7167,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

2
xep-0061.xml
View File

@ -64,7 +64,7 @@ default on a save action by the user).</p>
<update>auto|user</update> <update>auto|user</update>
</note> </note>
</message> </message>
]]></example> ]]></example>
<p>Any element not specified in the note should use the last known setting or client defaults, so that when a <p>Any element not specified in the note should use the last known setting or client defaults, so that when a
change is sent, only the changed elements are returned.</p> change is sent, only the changed elements are returned.</p>

78
xep-0065.xml
View File

@ -211,7 +211,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Target Replies to Service Discovery Request'><![CDATA[ <example caption='Target Replies to Service Discovery Request'><![CDATA[
<iq from='target@example.org/bar' <iq from='target@example.org/bar'
id='gr91cs53' id='gr91cs53'
@ -222,7 +222,7 @@
<feature var='http://jabber.org/protocol/bytestreams'/> <feature var='http://jabber.org/protocol/bytestreams'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Discovering Proxies' anchor='disco'> <section1 topic='Discovering Proxies' anchor='disco'>
@ -234,7 +234,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>The server will return all of the items it knows about.</p> <p>The server will return all of the items it knows about.</p>
<example caption='Server Replies to Service Discovery Request'><![CDATA[ <example caption='Server Replies to Service Discovery Request'><![CDATA[
<iq from='example.com' <iq from='example.com'
@ -247,7 +247,7 @@
<item jid='streamer.example.com' name='File Transfer Relay'/> <item jid='streamer.example.com' name='File Transfer Relay'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In this case, the "streamer.example.com" is a bytestreams proxy.</p> <p>In this case, the "streamer.example.com" is a bytestreams proxy.</p>
<p>For each item in the disco#items result, the Requester needs to query to determine if it is a bytestreams proxy.</p> <p>For each item in the disco#items result, the Requester needs to query to determine if it is a bytestreams proxy.</p>
<example caption='Requester Sends Service Discovery Request to Proxy'><![CDATA[ <example caption='Requester Sends Service Discovery Request to Proxy'><![CDATA[
@ -257,7 +257,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The proxy returns its information and the Requester inspects it to determine if it contains an identity of category "proxy" and type "bytestreams".</p> <p>The proxy returns its information and the Requester inspects it to determine if it contains an identity of category "proxy" and type "bytestreams".</p>
<example caption='Server Replies to Service Discovery Request'><![CDATA[ <example caption='Server Replies to Service Discovery Request'><![CDATA[
<iq from='streamer.example.com' <iq from='streamer.example.com'
@ -271,7 +271,7 @@
<feature var='http://jabber.org/protocol/bytestreams'/> <feature var='http://jabber.org/protocol/bytestreams'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Next the Requester needs to request the full network address to be used for bytestreaming through the Proxy. This is done by sending an IQ-get to the proxy containing a &QUERY; element qualified by the bytestreams namespace (not the service discovery namespace). <note>Before version 1.8 of this specification, the &QUERY; element in this use case possessed a 'sid' attribute; however, it is unnecessary for the Requester to specify the StreamID here and it would be harmful for the Proxy to reserve the StreamID at this point because the StreamID might never be used (thus forcing the Proxy to establish and maintain state about the bytestream) and because the Requester might use the Proxy's services for multiple different streams.</note></p> <p>Next the Requester needs to request the full network address to be used for bytestreaming through the Proxy. This is done by sending an IQ-get to the proxy containing a &QUERY; element qualified by the bytestreams namespace (not the service discovery namespace). <note>Before version 1.8 of this specification, the &QUERY; element in this use case possessed a 'sid' attribute; however, it is unnecessary for the Requester to specify the StreamID here and it would be harmful for the Proxy to reserve the StreamID at this point because the StreamID might never be used (thus forcing the Proxy to establish and maintain state about the bytestream) and because the Requester might use the Proxy's services for multiple different streams.</note></p>
<example caption='Requester Requests Network Address from Proxy'><![CDATA[ <example caption='Requester Requests Network Address from Proxy'><![CDATA[
<iq from='requester@example.com/foo' <iq from='requester@example.com/foo'
@ -280,7 +280,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/bytestreams'/> <query xmlns='http://jabber.org/protocol/bytestreams'/>
</iq> </iq>
]]></example> ]]></example>
<p>The Proxy replies by returning an IQ-result that contains its network address, structured using the &lt;streamhost/&gt; child of the &QUERY; element; the &lt;streamhost/&gt; element MUST possess the following attributes:</p> <p>The Proxy replies by returning an IQ-result that contains its network address, structured using the &lt;streamhost/&gt; child of the &QUERY; element; the &lt;streamhost/&gt; element MUST possess the following attributes:</p>
<ul> <ul>
<li><cite>host</cite> = the IP address or DNS domain name of the StreamHost for SOCKS5 communication over TCP (if the value is an IPv6 address, it MUST be formatted according to &rfc5952;, as is done in &xmppcore;)</li> <li><cite>host</cite> = the IP address or DNS domain name of the StreamHost for SOCKS5 communication over TCP (if the value is an IPv6 address, it MUST be formatted according to &rfc5952;, as is done in &xmppcore;)</li>
@ -300,7 +300,7 @@
port='7625'/> port='7625'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the Requester does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation might enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a &forbidden; error to the Requester.</p> <p>If the Requester does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation might enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a &forbidden; error to the Requester.</p>
<example caption='Requester is Forbidden to use Proxy'><![CDATA[ <example caption='Requester is Forbidden to use Proxy'><![CDATA[
<iq from='streamer.example.com' <iq from='streamer.example.com'
@ -312,7 +312,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p> <p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p>
<example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[ <example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[
<iq from='streamer.example.com' <iq from='streamer.example.com'
@ -324,7 +324,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p> <p>If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be &notallowed;.</p>
<example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[ <example caption='Proxy is Unable to Act as a StreamHost'><![CDATA[
<iq from='requester@example.com/foo' <iq from='requester@example.com/foo'
@ -336,7 +336,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Direct Connection' anchor='direct'> <section1 topic='Direct Connection' anchor='direct'>
@ -375,7 +375,7 @@ Requester Target
| Exchange data over S5B | | Exchange data over S5B |
| <============================> | | <============================> |
| | | |
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Protocol' anchor='direct-proto'> <section2 topic='Protocol' anchor='direct-proto'>
<section3 topic='Requester Initiates S5B Negotiation' anchor='direct-proto-initiate'> <section3 topic='Requester Initiates S5B Negotiation' anchor='direct-proto-initiate'>
@ -394,7 +394,7 @@ Requester Target
port='5086'/> port='5086'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the request is malformed (e.g., the &QUERY; element does not include the 'sid' attribute), the Target MUST return an error of &badrequest;.</p> <p>If the request is malformed (e.g., the &QUERY; element does not include the 'sid' attribute), the Target MUST return an error of &badrequest;.</p>
<p>Else if the Target is unwilling to accept the bytestream, it MUST return an error of &notacceptable; to the Requester.</p> <p>Else if the Target is unwilling to accept the bytestream, it MUST return an error of &notacceptable; to the Requester.</p>
<example caption='Target Refuses Bytestream'><![CDATA[ <example caption='Target Refuses Bytestream'><![CDATA[
@ -407,7 +407,7 @@ Requester Target
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.</p> <p>If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.</p>
</section3> </section3>
<section3 topic='Target Establishes SOCKS5 Connection with StreamHost/Requester' anchor='direct-proto-establish'> <section3 topic='Target Establishes SOCKS5 Connection with StreamHost/Requester' anchor='direct-proto-establish'>
@ -426,10 +426,10 @@ CMD = X'01'
ATYP = X'03' ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 0 DST.PORT = 0
]]></example> ]]></example>
<example caption='StreamHost Acknowledges Connection'><![CDATA[ <example caption='StreamHost Acknowledges Connection'><![CDATA[
STATUS = X'00' STATUS = X'00'
]]></example> ]]></example>
<p>When replying to the Target in accordance with Section 6 of <cite>RFC 1928</cite>, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.</p> <p>When replying to the Target in accordance with Section 6 of <cite>RFC 1928</cite>, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.</p>
<p>If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return an &notfound; error to the Requester.</p> <p>If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return an &notfound; error to the Requester.</p>
<example caption='Target Is Unable to Connect to Any StreamHost and Wishes to End Negotiation'><![CDATA[ <example caption='Target Is Unable to Connect to Any StreamHost and Wishes to End Negotiation'><![CDATA[
@ -442,7 +442,7 @@ STATUS = X'00'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Target Acknowledges Bytestream' anchor='direct-proto-ack'> <section3 topic='Target Acknowledges Bytestream' anchor='direct-proto-ack'>
<p>After the Target has authenticated with the StreamHost/Requester, it replies to the initiate request with an IQ-result whose &QUERY; element contains a &lt;streamhost-used/&gt; child that specifies which StreamHost was used (in this case, the StreamHost/Requester).</p> <p>After the Target has authenticated with the StreamHost/Requester, it replies to the initiate request with an IQ-result whose &QUERY; element contains a &lt;streamhost-used/&gt; child that specifies which StreamHost was used (in this case, the StreamHost/Requester).</p>
@ -456,7 +456,7 @@ STATUS = X'00'
<streamhost-used jid='requester@example.com/foo'/> <streamhost-used jid='requester@example.com/foo'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>At this point, the Requester knows which StreamHost was used by the Target and the parties are able to use the StreamHost/Requester to exchange data over the bytestream.</p> <p>At this point, the Requester knows which StreamHost was used by the Target and the parties are able to use the StreamHost/Requester to exchange data over the bytestream.</p>
</section3> </section3>
</section2> </section2>
@ -520,7 +520,7 @@ Requester Proxy Target
| Exchange data over S5B | | Exchange data over S5B |
| <=============================================================> | | <=============================================================> |
| | | | | |
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Protocol' anchor='mediated-proto'> <section2 topic='Protocol' anchor='mediated-proto'>
<section3 topic='Requester Initiates S5B Negotiation' anchor='mediated-proto-initiate'> <section3 topic='Requester Initiates S5B Negotiation' anchor='mediated-proto-initiate'>
@ -539,7 +539,7 @@ Requester Proxy Target
port='7625'/> port='7625'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.</p> <p>If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.</p>
</section3> </section3>
<section3 topic='Target Establishes SOCKS5 Connection with Proxy' anchor='mediated-proto-establish'> <section3 topic='Target Establishes SOCKS5 Connection with Proxy' anchor='mediated-proto-establish'>
@ -557,10 +557,10 @@ CMD = X'01'
ATYP = X'03' ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 0 DST.PORT = 0
]]></example> ]]></example>
<example caption='StreamHost Acknowledges Connection'><![CDATA[ <example caption='StreamHost Acknowledges Connection'><![CDATA[
STATUS = X'00' STATUS = X'00'
]]></example> ]]></example>
<p>When replying to the Target in accordance with Section 6 of <cite>RFC 1928</cite>, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.</p> <p>When replying to the Target in accordance with Section 6 of <cite>RFC 1928</cite>, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.</p>
</section3> </section3>
<section3 topic='Target Acknowledges Bytestream' anchor='mediated-proto-ack'> <section3 topic='Target Acknowledges Bytestream' anchor='mediated-proto-ack'>
@ -575,7 +575,7 @@ STATUS = X'00'
<streamhost-used jid='streamer.example.com'/> <streamhost-used jid='streamer.example.com'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>At this point, the Requester knows which StreamHost was used by the Target.</p> <p>At this point, the Requester knows which StreamHost was used by the Target.</p>
</section3> </section3>
<section3 topic='Requester Establishes SOCKS5 Connection with StreamHost' anchor='mediated-proto-initiator'> <section3 topic='Requester Establishes SOCKS5 Connection with StreamHost' anchor='mediated-proto-initiator'>
@ -585,10 +585,10 @@ CMD = X'01'
ATYP = X'03' ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 0 DST.PORT = 0
]]></example> ]]></example>
<example caption='StreamHost Acknowledges Connection to Requester'><![CDATA[ <example caption='StreamHost Acknowledges Connection to Requester'><![CDATA[
STATUS = X'00' STATUS = X'00'
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Activation of Bytestream' anchor='mediated-proto-activation'> <section3 topic='Activation of Bytestream' anchor='mediated-proto-activation'>
<p>Next the Requester needs to activate the bytestream with the Proxy. This is done by sending an IQ-set to the Proxy, including an &lt;activate/&gt; element whose XML character data specifies the full or bare JID of the Target.</p> <p>Next the Requester needs to activate the bytestream with the Proxy. This is done by sending an IQ-set to the Proxy, including an &lt;activate/&gt; element whose XML character data specifies the full or bare JID of the Target.</p>
@ -602,7 +602,7 @@ STATUS = X'00'
<activate>target@example.org/bar</activate> <activate>target@example.org/bar</activate>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Using this information, with the SID and from address on the packet, the Proxy is able to activate the stream by hashing the SID + Requester JID + Target JID and comparing the result against the DST.ADDR it has received from the Target and Receiver. Although this provides a reasonable level of trust that the activation request came from the Requester, it does not guard against active or even passive attacks against the bytestreams negotiation (see the <link url='#security'>Security Considerations</link> for information about potential hijacking of the negotiation).</p> <p>Using this information, with the SID and from address on the packet, the Proxy is able to activate the stream by hashing the SID + Requester JID + Target JID and comparing the result against the DST.ADDR it has received from the Target and Receiver. Although this provides a reasonable level of trust that the activation request came from the Requester, it does not guard against active or even passive attacks against the bytestreams negotiation (see the <link url='#security'>Security Considerations</link> for information about potential hijacking of the negotiation).</p>
<p>If the Proxy can fulfill the request, it MUST respond to the Requester with an IQ-result.</p> <p>If the Proxy can fulfill the request, it MUST respond to the Requester with an IQ-result.</p>
<example caption='Proxy Informs Requester of Activation'><![CDATA[ <example caption='Proxy Informs Requester of Activation'><![CDATA[
@ -610,7 +610,7 @@ STATUS = X'00'
id='oqx6t1c9' id='oqx6t1c9'
to='requester@example.com/foo' to='requester@example.com/foo'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>At this point the parties can begin exchanging data over the bytestream.</p> <p>At this point the parties can begin exchanging data over the bytestream.</p>
<p>If the Proxy cannot fulfill the request, it MUST return an IQ-error to the Requester; the following conditions are defined:</p> <p>If the Proxy cannot fulfill the request, it MUST return an IQ-error to the Requester; the following conditions are defined:</p>
<ul> <ul>
@ -640,7 +640,7 @@ STATUS = X'00'
port='7625'/> port='7625'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The MUC room will then forward the IQ-set to the Target's real JID with a 'from' address of the Requester's room JID.</p> <p>The MUC room will then forward the IQ-set to the Target's real JID with a 'from' address of the Requester's room JID.</p>
<example caption='MUC Room Forwards Initiation Request'><![CDATA[ <example caption='MUC Room Forwards Initiation Request'><![CDATA[
<iq from='room@conference.example.net/Rter' <iq from='room@conference.example.net/Rter'
@ -656,7 +656,7 @@ STATUS = X'00'
port='7625'/> port='7625'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Now the parties can proceed as defined for the direct or mediated connection. See the <link url='#security'>Security Considerations</link> for information about potential hijacking of the negotiation.</p> <p>Now the parties can proceed as defined for the direct or mediated connection. See the <link url='#security'>Security Considerations</link> for information about potential hijacking of the negotiation.</p>
</section1> </section1>
@ -671,7 +671,7 @@ STATUS = X'00'
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the Target supports UDP associations, it MUST include a feature of 'http://jabber.org/protocol/bytestreams#udp' in the service discovery result.</p> <p>If the Target supports UDP associations, it MUST include a feature of 'http://jabber.org/protocol/bytestreams#udp' in the service discovery result.</p>
<example caption='Target Replies to Service Discovery Request'><![CDATA[ <example caption='Target Replies to Service Discovery Request'><![CDATA[
<iq from='target@example.org/bar' <iq from='target@example.org/bar'
@ -687,7 +687,7 @@ STATUS = X'00'
<feature var='http://jabber.org/protocol/bytestreams#udp'/> <feature var='http://jabber.org/protocol/bytestreams#udp'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Requesting UDP Mode' anchor='udp-request'> <section2 topic='Requesting UDP Mode' anchor='udp-request'>
<p>UDP associations are requested by setting the 'mode' attribute to a value of "udp" rather than "tcp".</p> <p>UDP associations are requested by setting the 'mode' attribute to a value of "udp" rather than "tcp".</p>
@ -705,7 +705,7 @@ STATUS = X'00'
port='5086'/> port='5086'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='UDP Process' anchor='udp-process'> <section2 topic='UDP Process' anchor='udp-process'>
<p>There is one main difference between UDP mode and TCP mode: rather than simply establishing a TCP connection, the Target and/or Requester MUST (1) establish a UDP association and then (2) initialize the UDP channel. In particular:</p> <p>There is one main difference between UDP mode and TCP mode: rather than simply establishing a TCP connection, the Target and/or Requester MUST (1) establish a UDP association and then (2) initialize the UDP channel. In particular:</p>
@ -721,11 +721,11 @@ CMD = X'03'
ATYP = X'03' ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 0 DST.PORT = 0
]]></example> ]]></example>
<p>The StreamHost then acknowledges this request:</p> <p>The StreamHost then acknowledges this request:</p>
<example caption='StreamHost Acknowledges Request'><![CDATA[ <example caption='StreamHost Acknowledges Request'><![CDATA[
STATUS = X'00' STATUS = X'00'
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Initializing the UDP Channel' anchor='udp-process-init'> <section3 topic='Initializing the UDP Channel' anchor='udp-process-init'>
<p>After connecting to the StreamHost, the Target (direct connection) or both Target and Requester (mediated connection) MUST initialize the UDP channel. In order to do so, each sending entity MUST send a SOCKS5 UDP packet to the StreamHost on the same port used for the initial TCP connection (in the foregeoing example, a host of 192.168.4.1 and port of 5086), with DST.PORT set to '1' and DATA containing the sending entity's JID (i.e, the JID of either the Target or Requester).</p> <p>After connecting to the StreamHost, the Target (direct connection) or both Target and Requester (mediated connection) MUST initialize the UDP channel. In order to do so, each sending entity MUST send a SOCKS5 UDP packet to the StreamHost on the same port used for the initial TCP connection (in the foregeoing example, a host of 192.168.4.1 and port of 5086), with DST.PORT set to '1' and DATA containing the sending entity's JID (i.e, the JID of either the Target or Requester).</p>
@ -734,7 +734,7 @@ ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 1 DST.PORT = 1
DATA = Target or Requester JID DATA = Target or Requester JID
]]></example> ]]></example>
<p>Upon successful receipt by the StreamHost, the StreamHost MUST reply with a message notification indicating success:</p> <p>Upon successful receipt by the StreamHost, the StreamHost MUST reply with a message notification indicating success:</p>
<example caption='StreamHost Notifies Target or Requester of UDP Success'><![CDATA[ <example caption='StreamHost Notifies Target or Requester of UDP Success'><![CDATA[
<message <message
@ -744,7 +744,7 @@ DATA = Target or Requester JID
<udpsuccess xmlns='http://jabber.org/protocol/bytestreams' <udpsuccess xmlns='http://jabber.org/protocol/bytestreams'
dstaddr='Value of Hash'/> dstaddr='Value of Hash'/>
</message> </message>
]]></example> ]]></example>
<p>The &lt;udpsuccess/&gt; element indicates that the StreamHost has received a UDP initialization packet. This element has a single attribute containing the DST.ADDR that was used in the UDP packet.</p> <p>The &lt;udpsuccess/&gt; element indicates that the StreamHost has received a UDP initialization packet. This element has a single attribute containing the DST.ADDR that was used in the UDP packet.</p>
<p>If Target is unable to initialize the UDP channel, it MUST return a &remoteserver; error to RequesteRequester.</p> <p>If Target is unable to initialize the UDP channel, it MUST return a &remoteserver; error to RequesteRequester.</p>
<p>Note: Since UDP is not reliable, the Target SHOULD resend the UDP packet if the reply notification is not received within a short time (a 5-second retry is RECOMMENDED). The StreamHost SHOULD ignore duplicate UDP initialization packets once it has replied with a notification.</p> <p>Note: Since UDP is not reliable, the Target SHOULD resend the UDP packet if the reply notification is not received within a short time (a 5-second retry is RECOMMENDED). The StreamHost SHOULD ignore duplicate UDP initialization packets once it has replied with a notification.</p>
@ -758,7 +758,7 @@ ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID)
DST.PORT = 0 DST.PORT = 0
DATA = (payload) DATA = (payload)
]]></example> ]]></example>
<p>UDP packets sent from the StreamHost do not have any SOCKS5 headers, and so the payload shall be delivered as-is.</p> <p>UDP packets sent from the StreamHost do not have any SOCKS5 headers, and so the payload shall be delivered as-is.</p>
<p>The programming interface for a SOCKS5 Bytestreams-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system and SOCKS5 layer if applicable. In other words, 4 more octets smaller.</p> <p>The programming interface for a SOCKS5 Bytestreams-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system and SOCKS5 layer if applicable. In other words, 4 more octets smaller.</p>
</section2> </section2>
@ -874,7 +874,7 @@ DATA = (payload)
<doc>XEP-0065</doc> <doc>XEP-0065</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
@ -954,7 +954,7 @@ DATA = (payload)
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

26
xep-0066.xml
View File

@ -99,14 +99,14 @@
<desc>A license to Jabber!</desc> <desc>A license to Jabber!</desc>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The expected result is for the recipient to retrieve the file via an HTTP GET request and to then inform the sender of successful receipt of the file. The receiving application MUST NOT send the IQ result until it has retrieved the complete file (e.g., it MUST NOT send the IQ result if it has merely attempted to retrieve the file or the URL provided seems to be valid):</p> <p>The expected result is for the recipient to retrieve the file via an HTTP GET request and to then inform the sender of successful receipt of the file. The receiving application MUST NOT send the IQ result until it has retrieved the complete file (e.g., it MUST NOT send the IQ result if it has merely attempted to retrieve the file or the URL provided seems to be valid):</p>
<example caption="Recipient Informs Sender of Success"><![CDATA[ <example caption="Recipient Informs Sender of Success"><![CDATA[
<iq type='result' <iq type='result'
from='MaineBoy@jabber.org/home' from='MaineBoy@jabber.org/home'
to='stpeter@jabber.org/work' to='stpeter@jabber.org/work'
id='oob1'/> id='oob1'/>
]]></example> ]]></example>
<p>If the recipient attempts to retrieve the file but is unable to do so, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Found condition:</p> <p>If the recipient attempts to retrieve the file but is unable to do so, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Found condition:</p>
<example caption="Recipient Informs Sender of Failure"><![CDATA[ <example caption="Recipient Informs Sender of Failure"><![CDATA[
<iq type='error' <iq type='error'
@ -121,7 +121,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the recipient rejects the request outright, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Acceptable condition:</p> <p>If the recipient rejects the request outright, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Acceptable condition:</p>
<example caption="Recipient Rejects Request"><![CDATA[ <example caption="Recipient Rejects Request"><![CDATA[
<iq type='error' <iq type='error'
@ -136,7 +136,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='jabber:x:oob' anchor='x-oob'> <section1 topic='jabber:x:oob' anchor='x-oob'>
<p>The 'jabber:x:oob' namespace is used to communicate a URI to another user or application. This is done by including an &X; child element qualified by the 'jabber:x:oob' namespace in either a &MESSAGE; and &PRESENCE; stanza; the &X; child MUST contain a &lt;url/&gt; child specifying the URL of the resource, and MAY contain an optional &lt;desc/&gt; child describing the resource.</p> <p>The 'jabber:x:oob' namespace is used to communicate a URI to another user or application. This is done by including an &X; child element qualified by the 'jabber:x:oob' namespace in either a &MESSAGE; and &PRESENCE; stanza; the &X; child MUST contain a &lt;url/&gt; child specifying the URL of the resource, and MAY contain an optional &lt;desc/&gt; child describing the resource.</p>
@ -148,7 +148,7 @@
<url>http://www.jabber.org/images/psa-license.jpg</url> <url>http://www.jabber.org/images/psa-license.jpg</url>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports the out of band data protocol, it MUST report that by including a service discovery feature of "jabber:iq:oob" and/or "jabber:x:oob" in response to a &xep0030; information request:</p> <p>If an entity supports the out of band data protocol, it MUST report that by including a service discovery feature of "jabber:iq:oob" and/or "jabber:x:oob" in response to a &xep0030; information request:</p>
@ -159,7 +159,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery information response"><![CDATA[ <example caption="Service Discovery information response"><![CDATA[
<iq type='result' <iq type='result'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
@ -172,7 +172,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Use With Non-HTTP URI Schemes' anchor='nonhttp'> <section1 topic='Use With Non-HTTP URI Schemes' anchor='nonhttp'>
<p>The value of the &lt;url/&gt; element is not limited to URIs that conform to the http: URI scheme (as specified by &rfc2616;). For example, file transfers could also be effected using ftp: URIs as (specified by &rfc0959;). Going further afield, several existing Jabber clients use the callto: URI scheme to initiate voice conferencing via NetMeeting or GnomeMeeting. Other out-of-band communications could be initiated in a similar way via URI schemes such as sip: (as specified by &rfc3261;). All of these usages are allowed by the existing OOB namespaces, as long as the value of the &lt;url/&gt; element is a valid URI (as specified by &rfc3986;).</p> <p>The value of the &lt;url/&gt; element is not limited to URIs that conform to the http: URI scheme (as specified by &rfc2616;). For example, file transfers could also be effected using ftp: URIs as (specified by &rfc0959;). Going further afield, several existing Jabber clients use the callto: URI scheme to initiate voice conferencing via NetMeeting or GnomeMeeting. Other out-of-band communications could be initiated in a similar way via URI schemes such as sip: (as specified by &rfc3261;). All of these usages are allowed by the existing OOB namespaces, as long as the value of the &lt;url/&gt; element is a valid URI (as specified by &rfc3986;).</p>
@ -205,7 +205,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Stream Initiation Result'> <example caption='Stream Initiation Result'>
<![CDATA[ <![CDATA[
@ -225,7 +225,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption="Sender Initiates Request-Response"><![CDATA[ <example caption="Sender Initiates Request-Response"><![CDATA[
<iq type='set' <iq type='set'
@ -237,13 +237,13 @@
<url>http://www.shakespeare.lit/files/letter.txt</url> <url>http://www.shakespeare.lit/files/letter.txt</url>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="Recipient Informs Sender of Success"><![CDATA[ <example caption="Recipient Informs Sender of Success"><![CDATA[
<iq type='result' <iq type='result'
from='juliet@capulet.com/chamber' from='juliet@capulet.com/chamber'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
id='send1'/> id='send1'/>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>As with any mechanism that communicates a URI, care must be taken by the receiving application to ensure that the resource retrieved does not contain harmful or malicious data (e.g., a virus-infected file).</p> <p>As with any mechanism that communicates a URI, care must be taken by the receiving application to ensure that the resource retrieved does not contain harmful or malicious data (e.g., a virus-infected file).</p>
@ -283,7 +283,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='jabber:x:oob' anchor='schemas-x'> <section2 topic='jabber:x:oob' anchor='schemas-x'>
<code><![CDATA[ <code><![CDATA[
@ -312,7 +312,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

16
xep-0068.xml
View File

@ -138,7 +138,7 @@
</field> </field>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Correctly Specified FORM_TYPE' anchor='usecases-correct'> <section2 topic='Correctly Specified FORM_TYPE' anchor='usecases-correct'>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses Clark Notation in the field name.</p> <p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses Clark Notation in the field name.</p>
@ -167,7 +167,7 @@
</field> </field>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Incorrectly Specified FORM_TYPE' anchor='usecases-incorrect'> <section2 topic='Incorrectly Specified FORM_TYPE' anchor='usecases-incorrect'>
@ -189,7 +189,7 @@
</field> </field>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='IQ Example' anchor='usecases-IQ'> <section2 topic='IQ Example' anchor='usecases-IQ'>
<p>The following example shows a user's interaction with a Multi-User Chat room in order to register with the room.</p> <p>The following example shows a user's interaction with a Multi-User Chat room in order to register with the room.</p>
@ -201,7 +201,7 @@
id='reg1'> id='reg1'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Returns Registration Form'><![CDATA[ <example caption='Service Returns Registration Form'><![CDATA[
<iq <iq
type='result' type='result'
@ -256,7 +256,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='User Submits Registration Form'><![CDATA[ <example caption='User Submits Registration Form'><![CDATA[
<iq <iq
type='set' type='set'
@ -289,7 +289,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -322,7 +322,7 @@
type='the_field_type' type='the_field_type'
label='natural-language description of field'/> label='natural-language description of field'/>
</form_type> </form_type>
]]></code> ]]></code>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in XEP-0004.</p> <p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in XEP-0004.</p>
<p>In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:</p> <p>In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:</p>
<code><![CDATA[ <code><![CDATA[
@ -339,7 +339,7 @@
</option> </option>
</field> </field>
</form_type> </form_type>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
</section2> </section2>

26
xep-0070.xml
View File

@ -167,7 +167,7 @@
<p>An example is provided below:</p> <p>An example is provided below:</p>
<example caption='HTTP Client Makes Request (No Credentials)'><![CDATA[ <example caption='HTTP Client Makes Request (No Credentials)'><![CDATA[
GET https://files.shakespeare.lit:9345/missive.html HTTP/1.1 GET https://files.shakespeare.lit:9345/missive.html HTTP/1.1
]]></example> ]]></example>
<p>In order to avoid a round trip, the initial request MAY contain HTTP authorization credentials as described below.</p> <p>In order to avoid a round trip, the initial request MAY contain HTTP authorization credentials as described below.</p>
</section2> </section2>
<section2 topic='HTTP Server Returns Authenticate Response via HTTP' anchor='http-response'> <section2 topic='HTTP Server Returns Authenticate Response via HTTP' anchor='http-response'>
@ -181,7 +181,7 @@ WWW-Authenticate: Digest realm="xmpp",
nonce="ec2cc00f21f71acd35ab9be057970609", nonce="ec2cc00f21f71acd35ab9be057970609",
qop="auth", qop="auth",
algorithm="MD5" algorithm="MD5"
]]></example> ]]></example>
</section2> </section2>
<section2 topic='HTTP Client Sends Authorization Request via HTTP' anchor='http-authz'> <section2 topic='HTTP Client Sends Authorization Request via HTTP' anchor='http-authz'>
<p>The HTTP Client responds with an Authorization Request as defined in <cite>RFC 2616</cite>. The following rules apply:</p> <p>The HTTP Client responds with an Authorization Request as defined in <cite>RFC 2616</cite>. The following rules apply:</p>
@ -195,7 +195,7 @@ WWW-Authenticate: Digest realm="xmpp",
<p>(Refer to <cite>RFC 2617</cite> for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.)</p> <p>(Refer to <cite>RFC 2617</cite> for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.)</p>
<example caption='HTTP Client Makes Basic Authorization Request'><![CDATA[ <example caption='HTTP Client Makes Basic Authorization Request'><![CDATA[
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Digest Access Authentication Scheme' anchor='http-authz-digest'> <section3 topic='Digest Access Authentication Scheme' anchor='http-authz-digest'>
<p>The Digest Access Authentication scheme is defined in <cite>RFC 2617</cite>. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of <cite>RFC 3986</cite>.</p> <p>The Digest Access Authentication scheme is defined in <cite>RFC 2617</cite>. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of <cite>RFC 3986</cite>.</p>
@ -210,7 +210,7 @@ Authorization: Digest username="juliet@capulet.com",
cnonce="0a4f113b", cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Additional Authentication Schemes' anchor='http-authz-add'> <section3 topic='Additional Authentication Schemes' anchor='http-authz-add'>
<p>The HTTP Server MAY offer any other valid authentication scheme, instead of or in addition to the Basic and Digest schemes mentioned above, as long as the scheme makes it possible to specify a userid (JID) and transaction identifier as described above. However, it is RECOMMENDED to implement both the Basic and Digest authentication schemes.</p> <p>The HTTP Server MAY offer any other valid authentication scheme, instead of or in addition to the Basic and Digest schemes mentioned above, as long as the scheme makes it possible to specify a userid (JID) and transaction identifier as described above. However, it is RECOMMENDED to implement both the Basic and Digest authentication schemes.</p>
@ -235,7 +235,7 @@ Authorization: Digest username="juliet@capulet.com",
method='GET' method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/> url='https://files.shakespeare.lit:9345/missive.html'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Confirmation Request Sent via Message'><![CDATA[ <example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal' <message type='normal'
from='files.shakespeare.lit' from='files.shakespeare.lit'
@ -259,7 +259,7 @@ Authorization: Digest username="juliet@capulet.com",
method='GET' method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/> url='https://files.shakespeare.lit:9345/missive.html'/>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='XMPP Client Confirms Request via XMPP' anchor='xmpp-confirm'> <section2 topic='XMPP Client Confirms Request via XMPP' anchor='xmpp-confirm'>
<p>If the confirmation request was provided via an &IQ; stanza, the XMPP Client MUST respond to the request by sending an &IQ; stanza back to the XMPP Server. If the user wishes to confirm the request, the &IQ; response stanza MUST be of type "result" and MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes):</p> <p>If the confirmation request was provided via an &IQ; stanza, the XMPP Client MUST respond to the request by sending an &IQ; stanza back to the XMPP Server. If the user wishes to confirm the request, the &IQ; response stanza MUST be of type "result" and MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes):</p>
@ -268,7 +268,7 @@ Authorization: Digest username="juliet@capulet.com",
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
to='files.shakespeare.lit' to='files.shakespeare.lit'
id='ha000'/> id='ha000'/>
]]></example> ]]></example>
<p>If the user wishes to deny the request, the &IQ; response stanza MUST be of type "error", MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes), and MUST specify an error, which SHOULD be &notauthorized;:</p> <p>If the user wishes to deny the request, the &IQ; response stanza MUST be of type "error", MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes), and MUST specify an error, which SHOULD be &notauthorized;:</p>
<example caption='XMPP Client Denies Request via IQ'><![CDATA[ <example caption='XMPP Client Denies Request via IQ'><![CDATA[
<iq type='error' <iq type='error'
@ -283,7 +283,7 @@ Authorization: Digest username="juliet@capulet.com",
<not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the confirmation request was provided via a &MESSAGE; stanza and the &MESSAGE; contains a human-readable &BODY; or does not contain a &BODY; but the XMPP Client understands the 'http://jabber.org/protocol/http-auth' namespace, the XMPP Client SHOULD respond to the request by sending a &MESSAGE; stanza back to the XMPP Server. If the user wishes to confirm the request, the &MESSAGE; response stanza SHOULD be of type "normal", MUST mirror the &lt;thread/&gt; ID (if provided by the XMPP Server), and MUST contain the original &lt;confirm/&gt; child element:</p> <p>If the confirmation request was provided via a &MESSAGE; stanza and the &MESSAGE; contains a human-readable &BODY; or does not contain a &BODY; but the XMPP Client understands the 'http://jabber.org/protocol/http-auth' namespace, the XMPP Client SHOULD respond to the request by sending a &MESSAGE; stanza back to the XMPP Server. If the user wishes to confirm the request, the &MESSAGE; response stanza SHOULD be of type "normal", MUST mirror the &lt;thread/&gt; ID (if provided by the XMPP Server), and MUST contain the original &lt;confirm/&gt; child element:</p>
<example caption='XMPP Client Confirms Request via Message'><![CDATA[ <example caption='XMPP Client Confirms Request via Message'><![CDATA[
<message from='juliet@capulet.com/balcony' <message from='juliet@capulet.com/balcony'
@ -294,7 +294,7 @@ Authorization: Digest username="juliet@capulet.com",
method='GET' method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/> url='https://files.shakespeare.lit:9345/missive.html'/>
</message> </message>
]]></example> ]]></example>
<p>If the user wishes to deny the request, the &MESSAGE; response stanza MUST be of type "error", MUST mirror the &lt;thread/&gt; ID (if provided by the XMPP Server), MUST contain the original &lt;confirm/&gt; child element, and MUST specify an error, which SHOULD be &notauthorized;:</p> <p>If the user wishes to deny the request, the &MESSAGE; response stanza MUST be of type "error", MUST mirror the &lt;thread/&gt; ID (if provided by the XMPP Server), MUST contain the original &lt;confirm/&gt; child element, and MUST specify an error, which SHOULD be &notauthorized;:</p>
<example caption='XMPP Client Denies Request via Message'><![CDATA[ <example caption='XMPP Client Denies Request via Message'><![CDATA[
<message type='error' <message type='error'
@ -309,7 +309,7 @@ Authorization: Digest username="juliet@capulet.com",
<not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='HTTP Server Allows HTTP Client to Access Object' anchor='http-access'> <section2 topic='HTTP Server Allows HTTP Client to Access Object' anchor='http-access'>
<p>Once the XMPP Client has successfully confirmed the request, the XMPP Server forwards that confirmation to the HTTP Server, which allows access:</p> <p>Once the XMPP Client has successfully confirmed the request, the XMPP Server forwards that confirmation to the HTTP Server, which allows access:</p>
@ -319,11 +319,11 @@ Content-Type: text/html
Content-Length: 3032 Content-Length: 3032
... ...
]]></example> ]]></example>
<p>If the XMPP Client denied the request, the HTTP Server MUST return a Forbidden error:</p> <p>If the XMPP Client denied the request, the HTTP Server MUST return a Forbidden error:</p>
<example caption='HTTP Server Denies Access to Object'><![CDATA[ <example caption='HTTP Server Denies Access to Object'><![CDATA[
403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -392,6 +392,6 @@ Content-Length: 3032
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

28
xep-0071.xml
View File

@ -237,7 +237,7 @@
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>Technically speaking, there are three aspects to the approach taken herein:</p> <p>Technically speaking, there are three aspects to the approach taken herein:</p>
<ol> <ol>
<li>Definition of the &lt;html/&gt; "wrapper" element, which functions as an XMPP extension within XMPP &lt;message/&gt; stanzas.</li> <li>Definition of the &lt;html/&gt; "wrapper" element, which functions as an XMPP extension within XMPP &lt;message/&gt; stanzas.</li>
@ -605,7 +605,7 @@
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>This could be rendered as follows:</p> <p>This could be rendered as follows:</p>
<div class='example'> <div class='example'>
<p style='font-size: large'><em>Wow</em>, I&apos;m <span style='color:green'>green</span> with <strong>envy</strong>!</p> <p style='font-size: large'><em>Wow</em>, I&apos;m <span style='color:green'>green</span> with <strong>envy</strong>!</p>
@ -625,7 +625,7 @@
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>This could be rendered as follows:</p> <p>This could be rendered as follows:</p>
<div class='example'> <div class='example'>
<p>As Emerson said in his essay <cite>Self-Reliance</cite>:</p> <p>As Emerson said in his essay <cite>Self-Reliance</cite>:</p>
@ -649,7 +649,7 @@
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>This could be rendered as follows:</p> <p>This could be rendered as follows:</p>
<div class='indent'> <div class='indent'>
<p>Hey, are you licensed to <link url='http://www.jabber.org/'>Jabber</link>?</p> <p>Hey, are you licensed to <link url='http://www.jabber.org/'>Jabber</link>?</p>
@ -684,7 +684,7 @@
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>This could be rendered as follows:</p> <p>This could be rendered as follows:</p>
<div class='example'> <div class='example'>
<p>Here&apos;s my .plan for today:</p> <p>Here&apos;s my .plan for today:</p>
@ -729,7 +729,7 @@ That seems fine to me.
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>Although quoting received messages is relatively uncommon in IM, it does happen. This could be rendered as follows:</p> <p>Although quoting received messages is relatively uncommon in IM, it does happen. This could be rendered as follows:</p>
<div class='example'> <div class='example'>
<p>You wrote:</p> <p>You wrote:</p>
@ -757,7 +757,7 @@ That seems fine to me.
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>How multiple bodies would best be rendered will depend on the user agent and relevant application. For example, a specialized Jabber client that is used in foreign language instruction might show two languages side by side, whereas a dedicated IM client might show content only in a human user's preferred language as captured in the client configuration.</p> <p>How multiple bodies would best be rendered will depend on the user agent and relevant application. For example, a specialized Jabber client that is used in foreign language instruction might show two languages side by side, whereas a dedicated IM client might show content only in a human user's preferred language as captured in the client configuration.</p>
<example caption='Unrecognized Elements and Attributes'><![CDATA[ <example caption='Unrecognized Elements and Attributes'><![CDATA[
<message> <message>
@ -795,7 +795,7 @@ That seems fine to me.
</body> </body>
</html> </html>
</message> </message>
]]></example> ]]></example>
<p>Let us assume that the recipient's user agent recognizes neither the &lt;acronym/&gt; element (which is discouraged in XHTML-IM) nor the 'type' and 'start' attributes of the &lt;ol/&gt; element (which, after all, were deprecated in HTML 4.0), and that it does not render nested elements (e.g., the &lt;p/&gt; elements within the &lt;li/&gt; elements); in this case, it could render the content as follows (note that the element value is shown as text and the attribute value is not rendered):</p> <p>Let us assume that the recipient's user agent recognizes neither the &lt;acronym/&gt; element (which is discouraged in XHTML-IM) nor the 'type' and 'start' attributes of the &lt;ol/&gt; element (which, after all, were deprecated in HTML 4.0), and that it does not render nested elements (e.g., the &lt;p/&gt; elements within the &lt;li/&gt; elements); in this case, it could render the content as follows (note that the element value is shown as text and the attribute value is not rendered):</p>
<div class='example'> <div class='example'>
<p>The <acronym>XHTML</acronym> user agent conformance requirements say to ignore elements and attributes you don't understand, to wit:</p> <p>The <acronym>XHTML</acronym> user agent conformance requirements say to ignore elements and attributes you don't understand, to wit:</p>
@ -816,7 +816,7 @@ That seems fine to me.
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the queried entity supports XHTML-IM, it MUST return a &lt;feature/&gt; element with a 'var' attribute set to a value of "http://jabber.org/protocol/xhtml-im" in the IQ result.</p> <p>If the queried entity supports XHTML-IM, it MUST return a &lt;feature/&gt; element with a 'var' attribute set to a value of "http://jabber.org/protocol/xhtml-im" in the IQ result.</p>
<example caption='Contact Returns Disco Info Results'><![CDATA[ <example caption='Contact Returns Disco Info Results'><![CDATA[
<iq type='result' <iq type='result'
@ -829,7 +829,7 @@ That seems fine to me.
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Naturally, support can also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.</p> <p>Naturally, support can also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.</p>
</section2> </section2>
<section2 topic='Implicit Discovery' anchor='discovery-implicit'> <section2 topic='Implicit Discovery' anchor='discovery-implicit'>
@ -866,7 +866,7 @@ That seems fine to me.
<p>The Formal Public Identifier (FPI) for the XHTML-IM document type definition is:</p> <p>The Formal Public Identifier (FPI) for the XHTML-IM document type definition is:</p>
<code><![CDATA[ <code><![CDATA[
-//JSF//DTD Instant Messaging with XHTML//EN -//JSF//DTD Instant Messaging with XHTML//EN
]]></code> ]]></code>
<p>The fields of this FPI are as follows:</p> <p>The fields of this FPI are as follows:</p>
<ol> <ol>
<li>The leading field is "-", which indicates that this is a privately-defined resource.</li> <li>The leading field is "-", which indicates that this is a privately-defined resource.</li>
@ -963,7 +963,7 @@ That seems fine to me.
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='XHTML-IM Schema Driver' anchor='schemas-driver'> <section2 topic='XHTML-IM Schema Driver' anchor='schemas-driver'>
<p>The following schema defines the modularization schema driver for XHTML-IM.</p> <p>The following schema defines the modularization schema driver for XHTML-IM.</p>
@ -1031,7 +1031,7 @@ That seems fine to me.
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/> schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='XHTML-IM Content Model' anchor='schemas-model'> <section2 topic='XHTML-IM Content Model' anchor='schemas-model'>
<p>The following schema defines the content model for XHTML-IM.</p> <p>The following schema defines the content model for XHTML-IM.</p>
@ -1255,7 +1255,7 @@ That seems fine to me.
<!-- END TOP-LEVEL MIXES --> <!-- END TOP-LEVEL MIXES -->
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

36
xep-0072.xml
View File

@ -142,7 +142,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the responding entity supports the SOAP XMPP Binding and the requesting entity is not blocked from communicating with the responding entity, the responding entity MUST include a feature of "http://jabber.org/protocol/soap" in its reply and SHOULD specify a service discovery identity of "automation/soap".</p> <p>If the responding entity supports the SOAP XMPP Binding and the requesting entity is not blocked from communicating with the responding entity, the responding entity MUST include a feature of "http://jabber.org/protocol/soap" in its reply and SHOULD specify a service discovery identity of "automation/soap".</p>
<example caption="Responder replies regarding protocol support"><![CDATA[ <example caption="Responder replies regarding protocol support"><![CDATA[
<iq from='responder@example.com/soap-server' <iq from='responder@example.com/soap-server'
@ -154,7 +154,7 @@
<feature var='http://jabber.org/protocol/soap'/> <feature var='http://jabber.org/protocol/soap'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Exchanging SOAP Messages" anchor='exchange'> <section2 topic="Exchanging SOAP Messages" anchor='exchange'>
<p>When a requesting entity wants to interact with a responding entity via the SOAP XMPP Binding, it faces a fundamental choice: to use &IQ; stanzas or to use &MESSAGE; stanzas. The following guidelines may prove useful:</p> <p>When a requesting entity wants to interact with a responding entity via the SOAP XMPP Binding, it faces a fundamental choice: to use &IQ; stanzas or to use &MESSAGE; stanzas. The following guidelines may prove useful:</p>
@ -210,7 +210,7 @@
</env:Body> </env:Body>
</env:Envelope> </env:Envelope>
</iq> </iq>
]]></example> ]]></example>
<p>If the responding entity does not support the SOAP XMPP Binding, it SHOULD return a &unavailable; error:</p> <p>If the responding entity does not support the SOAP XMPP Binding, it SHOULD return a &unavailable; error:</p>
<example caption="Responding entity reports that it cannot handle SOAP messages"><![CDATA[ <example caption="Responding entity reports that it cannot handle SOAP messages"><![CDATA[
<iq type='result' to='requester@example.com/soap-client' id='soap1'> <iq type='result' to='requester@example.com/soap-client' id='soap1'>
@ -218,7 +218,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If a SOAP-related fault occurs, the mappings in <link url='#errors'>Error Handling</link> SHOULD be used.</p> <p>If a SOAP-related fault occurs, the mappings in <link url='#errors'>Error Handling</link> SHOULD be used.</p>
<example caption='Responding entity indicates SOAP fault'><![CDATA[ <example caption='Responding entity indicates SOAP fault'><![CDATA[
<iq type='error' to='requester@example.com/soap-client' id='soap1'> <iq type='error' to='requester@example.com/soap-client' id='soap1'>
@ -244,7 +244,7 @@
<Sender xmlns='http://jabber.org/protocol/soap#fault'/> <Sender xmlns='http://jabber.org/protocol/soap#fault'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the responding entity does not return an error, it MUST respond with an IQ of type "result":</p> <p>If the responding entity does not return an error, it MUST respond with an IQ of type "result":</p>
<example caption='Responding entity returns IQ-result'><![CDATA[ <example caption='Responding entity returns IQ-result'><![CDATA[
<iq from='responder@example.com/soap-server' <iq from='responder@example.com/soap-server'
@ -281,7 +281,7 @@
</env:Body> </env:Body>
</env:Envelope> </env:Envelope>
</iq> </iq>
]]></example> ]]></example>
<p>At this point the requesting entity could send another IQ-set:</p> <p>At this point the requesting entity could send another IQ-set:</p>
<example caption="Requesting entity sends another IQ-set"><![CDATA[ <example caption="Requesting entity sends another IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client' <iq from='requester@example.com/soap-client'
@ -315,7 +315,7 @@
</env:Body> </env:Body>
</env:Envelope> </env:Envelope>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Exchanging SOAP Messages Using XMPP Message Stanzas" anchor='exchange-message'> <section3 topic="Exchanging SOAP Messages Using XMPP Message Stanzas" anchor='exchange-message'>
<p>The process for exchanging SOAP messages using the XMPP &MESSAGE; stanza type is effectively no different from the use with &IQ; stanzas, except that message stanzas may be sent to bare JIDs (user@host) rather than full JIDs (user@host/resource), message stanzas may be stored for later delivery, etc. The following business rules apply:</p> <p>The process for exchanging SOAP messages using the XMPP &MESSAGE; stanza type is effectively no different from the use with &IQ; stanzas, except that message stanzas may be sent to bare JIDs (user@host) rather than full JIDs (user@host/resource), message stanzas may be stored for later delivery, etc. The following business rules apply:</p>
@ -403,7 +403,7 @@
date='2005-11-01T23:11Z'/> date='2005-11-01T23:11Z'/>
</sipub> </sipub>
</message> </message>
]]></example> ]]></example>
<p>The entity that is to receive the file SHOULD initiate the file transfer process sending an IQ-get to the sender, using the &lt;start xmlns='http://jabber.org/protocol/sipub'/&gt; element. This element contains the 'id' attribute to specify which published stream to retrieve:</p> <p>The entity that is to receive the file SHOULD initiate the file transfer process sending an IQ-get to the sender, using the &lt;start xmlns='http://jabber.org/protocol/sipub'/&gt; element. This element contains the 'id' attribute to specify which published stream to retrieve:</p>
<example caption='Receiver requests start of stream'><![CDATA[ <example caption='Receiver requests start of stream'><![CDATA[
<iq type='get' <iq type='get'
@ -413,7 +413,7 @@
<start xmlns='http://jabber.org/protocol/sipub' <start xmlns='http://jabber.org/protocol/sipub'
id='publish-2345'/> id='publish-2345'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the sender accepts the request, it responds with an IQ-result containing a &lt;starting/&gt; element. This element indicates the stream initiation identifier to be used:</p> <p>If the sender accepts the request, it responds with an IQ-result containing a &lt;starting/&gt; element. This element indicates the stream initiation identifier to be used:</p>
<example caption='Sender accepts request to start stream'><![CDATA[ <example caption='Sender accepts request to start stream'><![CDATA[
<iq type='result' <iq type='result'
@ -423,7 +423,7 @@
<starting xmlns='http://jabber.org/protocol/sipub' <starting xmlns='http://jabber.org/protocol/sipub'
sid='session-87651234'/> sid='session-87651234'/>
</iq> </iq>
]]></example> ]]></example>
<p>Then the sender begins the stream initiation negotiation:</p> <p>Then the sender begins the stream initiation negotiation:</p>
<example caption='Sender starts negotiation'><![CDATA[ <example caption='Sender starts negotiation'><![CDATA[
<iq type='set' <iq type='set'
@ -440,7 +440,7 @@
date='2005-11-01T23:11Z'/> date='2005-11-01T23:11Z'/>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>For details regarding file transfer and advertising of file transfer stream initiation requests, refer to <cite>XEP-0096</cite> and <cite>XEP-0137</cite>.</p> <p>For details regarding file transfer and advertising of file transfer stream initiation requests, refer to <cite>XEP-0096</cite> and <cite>XEP-0137</cite>.</p>
</section3> </section3>
<section3 topic="Including Links" anchor='data-link'> <section3 topic="Including Links" anchor='data-link'>
@ -480,7 +480,7 @@
<desc>John Q. Public</desc> <desc>John Q. Public</desc>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Alternatively, if all else fails, the file may be included as a SOAP representation header:</p> <p>Alternatively, if all else fails, the file may be included as a SOAP representation header:</p>
<example caption="IQ-set with SOAP representation header"><![CDATA[ <example caption="IQ-set with SOAP representation header"><![CDATA[
<iq from='requester@example.com/soap-client' <iq from='requester@example.com/soap-client'
@ -523,7 +523,7 @@
</env:Body> </env:Body>
</env:Envelope> </env:Envelope>
</iq> </iq>
]]></example> ]]></example>
<p>Naturally, in order to maximize the likelihood that the receiver will be able to retrieve the file, the sender MAY include the SI-pub extension, out-of-band-data extension, and SOAP representation header in the message stanza:</p> <p>Naturally, in order to maximize the likelihood that the receiver will be able to retrieve the file, the sender MAY include the SI-pub extension, out-of-band-data extension, and SOAP representation header in the message stanza:</p>
<example caption="Sender sends message with SI-pub, OOB, and representation header"><![CDATA[ <example caption="Sender sends message with SI-pub, OOB, and representation header"><![CDATA[
<message from='requester@example.com/soap-client' <message from='requester@example.com/soap-client'
@ -578,7 +578,7 @@
<desc>John Q. Public</desc> <desc>John Q. Public</desc>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic="Specifying a WSDL Definition" anchor='wsdl'> <section2 topic="Specifying a WSDL Definition" anchor='wsdl'>
@ -615,7 +615,7 @@
</service> </service>
</definitions> </definitions>
]]></example> ]]></example>
<p>Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &xep0030; or &xep0060;.</p> <p>Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &xep0030; or &xep0060;.</p>
</section2> </section2>
</section1> </section1>
@ -1112,7 +1112,7 @@
<doc>XEP-0072</doc> <doc>XEP-0072</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
@ -1150,7 +1150,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
@ -1187,7 +1187,7 @@
... ...
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
]]></example> ]]></example>
<p>Generic XMPP routers that conform to <cite>RFC 6120</cite> may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.</p> <p>Generic XMPP routers that conform to <cite>RFC 6120</cite> may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.</p>
<p>With regarding to exchange of associated data, an XMPP entity that functions as a gateway to other SOAP bindings it SHOULD use W3C-recommended protocols for transporting SOAP attachments over non-XMPP SOAP bindings (e.g., HTTP and SMTP) when communicating with non-XMPP entities.</p> <p>With regarding to exchange of associated data, an XMPP entity that functions as a gateway to other SOAP bindings it SHOULD use W3C-recommended protocols for transporting SOAP attachments over non-XMPP SOAP bindings (e.g., HTTP and SMTP) when communicating with non-XMPP entities.</p>
</section1> </section1>

14
xep-0074.xml
View File

@ -49,7 +49,7 @@
oper="uri://capulet.com/inventory#obtain" oper="uri://capulet.com/inventory#obtain"
target="poison"/> target="poison"/>
</iq> </iq>
]]> ]]>
</example> </example>
<p>Here we have the inventory.capulet.com component querying the security component as to whether juliet@ may obtain the requested poison.</p> <p>Here we have the inventory.capulet.com component querying the security component as to whether juliet@ may obtain the requested poison.</p>
<example caption="A response to the above query"> <example caption="A response to the above query">
@ -64,7 +64,7 @@
<allowed/> <allowed/>
</acl> </acl>
</iq> </iq>
]]> ]]>
</example> </example>
<p>Unfortunately, the response is in the affirmative and the romantic tragedy follows.</p> <p>Unfortunately, the response is in the affirmative and the romantic tragedy follows.</p>
</section1> </section1>
@ -88,7 +88,7 @@
<allowed/> <allowed/>
</acl> </acl>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Negative response (denied)'> <example caption='Negative response (denied)'>
<![CDATA[ <![CDATA[
@ -102,7 +102,7 @@
<denied/> <denied/>
</acl> </acl>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Error response'> <example caption='Error response'>
<![CDATA[ <![CDATA[
@ -115,7 +115,7 @@
target="poison"/> target="poison"/>
<error code="404">No information available</error> <error code="404">No information available</error>
</iq> </iq>
]]> ]]>
</example> </example>
</section1> </section1>
<section1 topic='Query List of ACL operations'> <section1 topic='Query List of ACL operations'>
@ -127,7 +127,7 @@
type="get" id="1234"> type="get" id="1234">
<query xmlns="http://jabber.org/protocol/sac"/> <query xmlns="http://jabber.org/protocol/sac"/>
</iq> </iq>
]]> ]]>
</example> </example>
<p>The to jid must then respond with a list of operations, if the jid supports SAC.</p> <p>The to jid must then respond with a list of operations, if the jid supports SAC.</p>
<example caption='response to the query'> <example caption='response to the query'>
@ -141,7 +141,7 @@
<oper uri="uri://capulet.com/inventory#remove"/> <oper uri="uri://capulet.com/inventory#remove"/>
</query> </query>
</iq> </iq>
]]> ]]>
</example> </example>
</section1> </section1>
<section1 topic='Integrating with Service Discovery'> <section1 topic='Integrating with Service Discovery'>

18
xep-0075.xml
View File

@ -592,7 +592,7 @@
to='TrackSegment@trainset.example.com/134' > to='TrackSegment@trainset.example.com/134' >
<describe xmlns='jabber:iq:joap' /> <describe xmlns='jabber:iq:joap' />
</iq> </iq>
]]> ]]>
</example> </example>
<p>The instance returns this stanza to the JOAP client.</p> <p>The instance returns this stanza to the JOAP client.</p>
<example caption='Description of an Instance'><![CDATA[ <example caption='Description of an Instance'><![CDATA[
@ -665,7 +665,7 @@
to='Station@trainset.example.com/Paddington'> to='Station@trainset.example.com/Paddington'>
<read xmlns='jabber:iq:joap' /> <read xmlns='jabber:iq:joap' />
</iq> </iq>
]]> ]]>
</example> </example>
<p>In return, the instance would send this stanza to the <p>In return, the instance would send this stanza to the
client:</p> client:</p>
@ -717,7 +717,7 @@
<name>cars</name> <name>cars</name>
</read> </read>
</iq> </iq>
]]> ]]>
</example> </example>
<p>In return, the instance would send this stanza to the <p>In return, the instance would send this stanza to the
client:</p> client:</p>
@ -799,7 +799,7 @@
<newAddress>PassengerCar@trainset.example.com/866</newAddress> <newAddress>PassengerCar@trainset.example.com/866</newAddress>
</add> </add>
</iq> </iq>
]]></example> ]]></example>
<p>Note that the class created a new instance identifier, 866, <p>Note that the class created a new instance identifier, 866,
for the new instance. Further communications from the client for the new instance. Further communications from the client
would use the full instance address returned.</p> would use the full instance address returned.</p>
@ -854,7 +854,7 @@
</attribute> </attribute>
</edit> </edit>
</iq> </iq>
]]></example> ]]></example>
<p>The client would return the following stanza:</p> <p>The client would return the following stanza:</p>
<example caption='Results of Editing an Instance'><![CDATA[ <example caption='Results of Editing an Instance'><![CDATA[
<iq type='result' <iq type='result'
@ -863,7 +863,7 @@
from='PassengerCar@trainset.example.com/199'> from='PassengerCar@trainset.example.com/199'>
<edit xmlns='jabber:iq:joap' /> <edit xmlns='jabber:iq:joap' />
</iq> </iq>
]]></example> ]]></example>
<p>If a client wanted to change the name of a Building, it <p>If a client wanted to change the name of a Building, it
would send the following stanza to the instance:</p> would send the following stanza to the instance:</p>
<example caption='Editing an Instance'><![CDATA[ <example caption='Editing an Instance'><![CDATA[
@ -878,7 +878,7 @@
</attribute> </attribute>
</edit> </edit>
</iq> </iq>
]]></example> ]]></example>
<p>The results would be as follows:</p> <p>The results would be as follows:</p>
<example caption='Results of Editing an Instance'><![CDATA[ <example caption='Results of Editing an Instance'><![CDATA[
<iq type='result' <iq type='result'
@ -889,7 +889,7 @@
<newAddress>Building@trainset.example.com/SmithFamilyHome</newAddress> <newAddress>Building@trainset.example.com/SmithFamilyHome</newAddress>
</edit> </edit>
</iq> </iq>
]]></example> ]]></example>
<p>Note that the instance indentifier, and thus the instance <p>Note that the instance indentifier, and thus the instance
address, of the instance has changed. The <tt>from</tt> part address, of the instance has changed. The <tt>from</tt> part
of the IQ, however, contains the old address.</p> of the IQ, however, contains the old address.</p>
@ -1814,6 +1814,6 @@
boolean switchTo(TrackSegment) boolean switchTo(TrackSegment)
Station: TrackSegment, Building Station: TrackSegment, Building
]]></example> ]]></example>
</section1> </section1>
</xep> </xep>

10
xep-0076.xml
View File

@ -54,7 +54,7 @@
</body> </body>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Evil Presence'> <section2 topic='Evil Presence'>
<p>If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p> <p>If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p>
@ -64,7 +64,7 @@
<status>Fomenting dissension</status> <status>Fomenting dissension</status>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Evil IQs'> <section2 topic='Evil IQs'>
<p>If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p> <p>If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p>
@ -79,7 +79,7 @@
</query> </query>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
@ -91,7 +91,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq from='iago@shakespeare.lit/pda' <iq from='iago@shakespeare.lit/pda'
id='disco1' id='disco1'
@ -101,7 +101,7 @@
<feature var='http://jabber.org/protocol/evil'/> <feature var='http://jabber.org/protocol/evil'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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>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>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>

82
xep-0077.xml
View File

@ -168,7 +168,7 @@
<iq type='get' id='reg1' to='shakespeare.lit'> <iq type='get' id='reg1' to='shakespeare.lit'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the entity is not already registered and the host supports In-Band Registration, the host MUST inform the entity of the required registration fields. If the host does not support In-Band Registration, it MUST return a &unavailable; error. If the host is redirecting registration requests to some other medium (e.g., a website), it MAY return an &lt;instructions/&gt; element only, as shown in the <link url="#redirect">Redirection</link> section of this document.</p> <p>If the entity is not already registered and the host supports In-Band Registration, the host MUST inform the entity of the required registration fields. If the host does not support In-Band Registration, it MUST return a &unavailable; error. If the host is redirecting registration requests to some other medium (e.g., a website), it MAY return an &lt;instructions/&gt; element only, as shown in the <link url="#redirect">Redirection</link> section of this document.</p>
<example caption='Host Returns Registration Fields to Entity'><![CDATA[ <example caption='Host Returns Registration Fields to Entity'><![CDATA[
<iq type='result' id='reg1'> <iq type='result' id='reg1'>
@ -182,7 +182,7 @@
<email/> <email/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the host determines (based on the 'from' address) that the entity is already registered, the IQ result that it sends in response to the IQ get MUST contain an empty &lt;registered/&gt; element (indicating that the entity is already registered), SHOULD contain the registration information currently on file for the entity (although the &lt;password/&gt; element MAY be empty), and SHOULD contain an &lt;instructions/&gt; element (whose XML character data MAY be modified to reflect the fact that the entity is currently registered).</p> <p>If the host determines (based on the 'from' address) that the entity is already registered, the IQ result that it sends in response to the IQ get MUST contain an empty &lt;registered/&gt; element (indicating that the entity is already registered), SHOULD contain the registration information currently on file for the entity (although the &lt;password/&gt; element MAY be empty), and SHOULD contain an &lt;instructions/&gt; element (whose XML character data MAY be modified to reflect the fact that the entity is currently registered).</p>
<p>If the host is an instant messaging server, it SHOULD assume that the requesting entity is unregistered at this stage unless the entity has already authenticated (for details, see the <link url="#usecases-register-server">Registration with a Server</link> section below).</p> <p>If the host is an instant messaging server, it SHOULD assume that the requesting entity is unregistered at this stage unless the entity has already authenticated (for details, see the <link url="#usecases-register-server">Registration with a Server</link> section below).</p>
<example caption='Host Informs Entity of Current Registration'><![CDATA[ <example caption='Host Informs Entity of Current Registration'><![CDATA[
@ -194,7 +194,7 @@
<email>juliet@capulet.com</email> <email>juliet@capulet.com</email>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the entity is not already registered, the entity SHOULD provide the required information.</p> <p>If the entity is not already registered, the entity SHOULD provide the required information.</p>
<example caption='Entity Provides Required Information'><![CDATA[ <example caption='Entity Provides Required Information'><![CDATA[
<iq type='set' id='reg2'> <iq type='set' id='reg2'>
@ -204,11 +204,11 @@
<email>bard@shakespeare.lit</email> <email>bard@shakespeare.lit</email>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The requesting entity MUST provide information for all of the elements (other than &lt;instructions/&gt;) contained in the IQ result.</p> <p>Note: The requesting entity MUST provide information for all of the elements (other than &lt;instructions/&gt;) contained in the IQ result.</p>
<example caption='Host Informs Entity of Successful Registration'><![CDATA[ <example caption='Host Informs Entity of Successful Registration'><![CDATA[
<iq type='result' id='reg2'/> <iq type='result' id='reg2'/>
]]></example> ]]></example>
<p>Alternatively, registration may fail. Possible causes of failure include a username conflict (the desired username is already in use by another entity) and the fact that the requesting entity neglected to provide all of the required information.</p> <p>Alternatively, registration may fail. Possible causes of failure include a username conflict (the desired username is already in use by another entity) and the fact that the requesting entity neglected to provide all of the required information.</p>
<example caption='Host Informs Entity of Failed Registration (Username Conflict)'><![CDATA[ <example caption='Host Informs Entity of Failed Registration (Username Conflict)'><![CDATA[
<iq type='error' id='reg2'> <iq type='error' id='reg2'>
@ -221,7 +221,7 @@
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the requesting entity does not provide all of the requested information during registration <note>This includes providing an empty password element or a password element that contains no XML character data, i.e., either &lt;password/&gt; or &lt;password&gt;&lt;/password&gt;.</note> then the server or service MUST return a &notacceptable; error to the requesting entity.</p> <p>If the requesting entity does not provide all of the requested information during registration <note>This includes providing an empty password element or a password element that contains no XML character data, i.e., either &lt;password/&gt; or &lt;password&gt;&lt;/password&gt;.</note> then the server or service MUST return a &notacceptable; error to the requesting entity.</p>
<example caption='Host Informs Entity of Failed Registration (Some Required Information Not Provided)'><![CDATA[ <example caption='Host Informs Entity of Failed Registration (Some Required Information Not Provided)'><![CDATA[
<iq type='error' id='reg2'> <iq type='error' id='reg2'>
@ -233,7 +233,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the host requires additional information above and beyond the data elements specified in the schema, it SHOULD use Data Forms as described in the <link url='#extensibility'>Extensibility</link> section of this document. (The next three examples show registration of an existing account with a third-party service, not of an entity with a server for the purpose of account registration.)</p> <p>If the host requires additional information above and beyond the data elements specified in the schema, it SHOULD use Data Forms as described in the <link url='#extensibility'>Extensibility</link> section of this document. (The next three examples show registration of an existing account with a third-party service, not of an entity with a server for the purpose of account registration.)</p>
<example caption='Entity Requests Registration Fields from Host'><![CDATA[ <example caption='Entity Requests Registration Fields from Host'><![CDATA[
<iq type='get' <iq type='get'
@ -242,7 +242,7 @@
id='reg3'> id='reg3'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Host Returns Registration Form to Entity'><![CDATA[ <example caption='Host Returns Registration Form to Entity'><![CDATA[
<iq type='result' <iq type='result'
from='contests.shakespeare.lit' from='contests.shakespeare.lit'
@ -278,7 +278,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The user then SHOULD return the form:</p> <p>The user then SHOULD return the form:</p>
<example caption='User Submits Registration Form'><![CDATA[ <example caption='User Submits Registration Form'><![CDATA[
<iq type='set' <iq type='set'
@ -305,7 +305,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<section3 topic='Registration with a Server' anchor='usecases-register-server'> <section3 topic='Registration with a Server' anchor='usecases-register-server'>
<p>Special care must be taken when an unregistered entity interacts with a server rather than a service. Normally, a server enables in-band registration so that entities can "bootstrap" their participation in the Jabber network; this bootstrapping happens when an unregistered and unauthenticated entity opens a TCP connection to a server and immediately completes the registration use case with the server, then authenticates using the newly-registered identity. As noted, when a server receives an IQ-get for registration information, it SHOULD assume that the requesting entity is unregistered unless the entity has already authenticated.</p> <p>Special care must be taken when an unregistered entity interacts with a server rather than a service. Normally, a server enables in-band registration so that entities can "bootstrap" their participation in the Jabber network; this bootstrapping happens when an unregistered and unauthenticated entity opens a TCP connection to a server and immediately completes the registration use case with the server, then authenticates using the newly-registered identity. As noted, when a server receives an IQ-get for registration information, it SHOULD assume that the requesting entity is unregistered unless the entity has already authenticated.</p>
<p>Depending on local service provisioning, a server MAY return a &notacceptable; stanza error if an unregistered entity attempts to register too many times before authenticating or if an entity attempts to register a second identity after successfully completing the registration use case; a server MAY also return a &lt;not-authorized/&gt; stream error if the unregistered entity waits too long before authenticating or attempts to complete a task other than authentication after successfully completing the registration use case.</p> <p>Depending on local service provisioning, a server MAY return a &notacceptable; stanza error if an unregistered entity attempts to register too many times before authenticating or if an entity attempts to register a second identity after successfully completing the registration use case; a server MAY also return a &lt;not-authorized/&gt; stream error if the unregistered entity waits too long before authenticating or attempts to complete a task other than authentication after successfully completing the registration use case.</p>
@ -319,10 +319,10 @@
<remove/> <remove/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Host Informs Entity of Successful Cancellation'><![CDATA[ <example caption='Host Informs Entity of Successful Cancellation'><![CDATA[
<iq type='result' to='bill@shakespeare.lit/globe' id='unreg1'/> <iq type='result' to='bill@shakespeare.lit/globe' id='unreg1'/>
]]></example> ]]></example>
<p>There are two scenarios:</p> <p>There are two scenarios:</p>
<ol> <ol>
<li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &xmppim;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li> <li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &xmppim;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
@ -343,21 +343,21 @@
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Host Informs Client of Failed Cancellation (Forbidden)'><![CDATA[ <example caption='Host Informs Client of Failed Cancellation (Forbidden)'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'>
<error code='401' type='cancel'> <error code='401' type='cancel'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Informs Client of Failed Cancellation (Not Allowed)'><![CDATA[ <example caption='Server Informs Client of Failed Cancellation (Not Allowed)'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'>
<error code='405' type='cancel'> <error code='405' type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>A given deployment MAY choose to require additional information (such as the old password or previously-gathered personal information) before cancelling the registration. In order to do so, the server or service SHOULD return a Data Form in the error stanza:</p> <p>A given deployment MAY choose to require additional information (such as the old password or previously-gathered personal information) before cancelling the registration. In order to do so, the server or service SHOULD return a Data Form in the error stanza:</p>
<example caption='Server Returns Cancellation Form With Error'><![CDATA[ <example caption='Server Returns Cancellation Form With Error'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'>
@ -383,7 +383,7 @@
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>The user then SHOULD return the form:</p> <p>The user then SHOULD return the form:</p>
<example caption='User Returns Cancellation Form'><![CDATA[ <example caption='User Returns Cancellation Form'><![CDATA[
<iq type='set' from='bill@shakespeare.lit/globe' to='shakespeare.lit' id='unreg2'> <iq type='set' from='bill@shakespeare.lit/globe' to='shakespeare.lit' id='unreg2'>
@ -404,7 +404,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='User Changes Password' anchor='usecases-changepw'> <section2 topic='User Changes Password' anchor='usecases-changepw'>
<p>The 'jabber:iq:register' namespace enables a user to change his or her password with a server or service. Once registered, the user can change passwords by sending an XML stanza of the following form:</p> <p>The 'jabber:iq:register' namespace enables a user to change his or her password with a server or service. Once registered, the user can change passwords by sending an XML stanza of the following form:</p>
@ -415,12 +415,12 @@
<password>newpass</password> <password>newpass</password>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Because the password change request contains the password in plain text, a client SHOULD NOT send such a request unless the underlying stream is encrypted (using SSL or TLS) and the client has verified that the server certificate is signed by a trusted certificate authority. A given deployment MAY choose to disable password changes if the stream is not properly encrypted, to disable in-band password changes, or to require additional information (such as the old password or previously-gathered personal information) before changing the password.</p> <p>Because the password change request contains the password in plain text, a client SHOULD NOT send such a request unless the underlying stream is encrypted (using SSL or TLS) and the client has verified that the server certificate is signed by a trusted certificate authority. A given deployment MAY choose to disable password changes if the stream is not properly encrypted, to disable in-band password changes, or to require additional information (such as the old password or previously-gathered personal information) before changing the password.</p>
<p>If the user provides an empty password element or a password element that contains no XML character data (i.e., either &lt;password/&gt; or &lt;password&gt;&lt;/password&gt;), the server or service MUST NOT change the password to a null value, but instead MUST maintain the existing password.</p> <p>If the user provides an empty password element or a password element that contains no XML character data (i.e., either &lt;password/&gt; or &lt;password&gt;&lt;/password&gt;), the server or service MUST NOT change the password to a null value, but instead MUST maintain the existing password.</p>
<example caption='Host Informs Client of Successful Password Change'><![CDATA[ <example caption='Host Informs Client of Successful Password Change'><![CDATA[
<iq type='result' id='change1'/> <iq type='result' id='change1'/>
]]></example> ]]></example>
<p>Several error conditions are possible:</p> <p>Several error conditions are possible:</p>
<table caption='Password Change Error Cases'> <table caption='Password Change Error Cases'>
<tr><th>Condition</th><th>Description</th></tr> <tr><th>Condition</th><th>Description</th></tr>
@ -436,21 +436,21 @@
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Host Informs Client of Failed Password Change (Not Authorized)'><![CDATA[ <example caption='Host Informs Client of Failed Password Change (Not Authorized)'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'>
<error code='401' type='modify'> <error code='401' type='modify'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Informs Client of Failed Password Change (Not Allowed)'><![CDATA[ <example caption='Server Informs Client of Failed Password Change (Not Allowed)'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'>
<error code='405' type='cancel'> <error code='405' type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>In order to require additional information before changing the password, the server or service SHOULD return a Data Form in the error stanza:</p> <p>In order to require additional information before changing the password, the server or service SHOULD return a Data Form in the error stanza:</p>
<example caption='Server Returns Password Change Form With Error'><![CDATA[ <example caption='Server Returns Password Change Form With Error'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'> <iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='change1'>
@ -479,7 +479,7 @@
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>The user then SHOULD return the form:</p> <p>The user then SHOULD return the form:</p>
<example caption='User Returns Password Change Form'><![CDATA[ <example caption='User Returns Password Change Form'><![CDATA[
<iq type='set' from='bill@shakespeare.lit/globe' to='shakespeare.lit' id='change2'> <iq type='set' from='bill@shakespeare.lit/globe' to='shakespeare.lit' id='change2'>
@ -503,7 +503,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Extensibility' anchor='extensibility'> <section1 topic='Extensibility' anchor='extensibility'>
@ -533,7 +533,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Precedence Order' anchor='precedence'> <section1 topic='Precedence Order' anchor='precedence'>
<p>Given the foregoing discussion, it is evident that an entity could receive any combination of iq:register, x:data, and x:oob namespaces from a service in response to a request for information. The precedence order is as follows:</p> <p>Given the foregoing discussion, it is evident that an entity could receive any combination of iq:register, x:data, and x:oob namespaces from a service in response to a request for information. The precedence order is as follows:</p>
@ -604,7 +604,7 @@
<stream:features> <stream:features>
<register xmlns='http://jabber.org/features/iq-register'/> <register xmlns='http://jabber.org/features/iq-register'/>
</stream:features> </stream:features>
]]></example> ]]></example>
<p>A server SHOULD NOT advertise in-band registration to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p> <p>A server SHOULD NOT advertise in-band registration to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>
</section1> </section1>
<section1 topic='Error Handling' anchor='errors'> <section1 topic='Error Handling' anchor='errors'>
@ -619,7 +619,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service discovery information response"><![CDATA[ <example caption="Service discovery information response"><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='jzg2d175' id='jzg2d175'
@ -629,7 +629,7 @@
<feature var='jabber:iq:register'/> <feature var='jabber:iq:register'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Although connecting clients typically determine support during stream negotiation via the stream feature, the service discovery feature is helpful for server-to-server connections as well as for clients that are already connected (e.g., to determine if password changes are possible in-band).</p> <p>Although connecting clients typically determine support during stream negotiation via the stream feature, the service discovery feature is helpful for server-to-server connections as well as for clients that are already connected (e.g., to determine if password changes are possible in-band).</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
@ -652,13 +652,13 @@
<p>The 'jabber:iq:register' namespace include a mechanism for creating a registration. The registered querytype for doing so is "register".</p> <p>The 'jabber:iq:register' namespace include a mechanism for creating a registration. The registered querytype for doing so is "register".</p>
<example caption='Register Action: IRI/URI'><![CDATA[ <example caption='Register Action: IRI/URI'><![CDATA[
xmpp:marlowe.shakespeare.lit?register xmpp:marlowe.shakespeare.lit?register
]]></example> ]]></example>
<p>Because registration is a two-step process, the application MUST then send an IQ-get to the entity in order to retrieve the required registration fields:</p> <p>Because registration is a two-step process, the application MUST then send an IQ-get to the entity in order to retrieve the required registration fields:</p>
<example caption='Retrieving Registration Fields'><![CDATA[ <example caption='Retrieving Registration Fields'><![CDATA[
<iq to='marlowe.shakespeare.lit' type='get'> <iq to='marlowe.shakespeare.lit' type='get'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Receiving Registration Fields'><![CDATA[ <example caption='Receiving Registration Fields'><![CDATA[
<iq from='marlowe.shakespeare.lit' type='result'> <iq from='marlowe.shakespeare.lit' type='result'>
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
@ -666,7 +666,7 @@ xmpp:marlowe.shakespeare.lit?register
<password/> <password/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The application MUST then present an appropriate interface that enables the user to complete the registration form. Once the user provides the information, the application MUST send an IQ-set to the entity.</p> <p>The application MUST then present an appropriate interface that enables the user to complete the registration form. Once the user provides the information, the application MUST send an IQ-set to the entity.</p>
<example caption='Sending Registration Information'><![CDATA[ <example caption='Sending Registration Information'><![CDATA[
<iq to='marlowe.shakespeare.lit' type='set'> <iq to='marlowe.shakespeare.lit' type='set'>
@ -675,7 +675,7 @@ xmpp:marlowe.shakespeare.lit?register
<password>R0m30</password> <password>R0m30</password>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The following submission registers the "register" querytype.</p> <p>The following submission registers the "register" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -684,20 +684,20 @@ xmpp:marlowe.shakespeare.lit?register
<desc>enables registering with a server or service</desc> <desc>enables registering with a server or service</desc>
<doc>XEP-0077</doc> <doc>XEP-0077</doc>
</querytype> </querytype>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='unregister' anchor='registrar-querytypes-unregister'> <section3 topic='unregister' anchor='registrar-querytypes-unregister'>
<p>The 'jabber:iq:register' namespace include a mechanism for cancelling an existing registration. The registered querytype for doing so is "unregister".</p> <p>The 'jabber:iq:register' namespace include a mechanism for cancelling an existing registration. The registered querytype for doing so is "unregister".</p>
<example caption='Unregister Action: IRI/URI'><![CDATA[ <example caption='Unregister Action: IRI/URI'><![CDATA[
xmpp:marlowe.shakespeare.lit?unregister xmpp:marlowe.shakespeare.lit?unregister
]]></example> ]]></example>
<example caption='Unregister Action: Resulting Stanza'><![CDATA[ <example caption='Unregister Action: Resulting Stanza'><![CDATA[
<iq to='marlowe.shakespeare.lit' type='set'> <iq to='marlowe.shakespeare.lit' type='set'>
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
<remove/> <remove/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The following submission registers the "unregister" querytype.</p> <p>The following submission registers the "unregister" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -706,7 +706,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<desc>enables cancellation of a registration with a server or service</desc> <desc>enables cancellation of a registration with a server or service</desc>
<doc>XEP-0077</doc> <doc>XEP-0077</doc>
</querytype> </querytype>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'> <section2 topic='Field Standardization' anchor='registrar-formtypes'>
@ -786,7 +786,7 @@ xmpp:marlowe.shakespeare.lit?unregister
type='text-single' type='text-single'
label='Session key for transaction (obsolete)'/> label='Session key for transaction (obsolete)'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='Cancellation' anchor='registrar-formtypes-cancel'> <section3 topic='Cancellation' anchor='registrar-formtypes-cancel'>
<code><![CDATA[ <code><![CDATA[
@ -803,7 +803,7 @@ xmpp:marlowe.shakespeare.lit?unregister
type='text-single' type='text-single'
label='Account name associated with the user'/> label='Account name associated with the user'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='Change Password' anchor='registrar-formtypes-changepassword'> <section3 topic='Change Password' anchor='registrar-formtypes-changepassword'>
<code><![CDATA[ <code><![CDATA[
@ -824,7 +824,7 @@ xmpp:marlowe.shakespeare.lit?unregister
type='text-single' type='text-single'
label='Account name associated with the user'/> label='Account name associated with the user'/>
</form_type> </form_type>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -894,7 +894,7 @@ xmpp:marlowe.shakespeare.lit?unregister
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Stream Feature' anchor='schemas-streams'> <section2 topic='Stream Feature' anchor='schemas-streams'>
<code><![CDATA[ <code><![CDATA[
@ -922,7 +922,7 @@ xmpp:marlowe.shakespeare.lit?unregister
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

22
xep-0078.xml
View File

@ -185,7 +185,7 @@
<iq type='get' to='shakespeare.lit' id='auth1'> <iq type='get' to='shakespeare.lit' id='auth1'>
<query xmlns='jabber:iq:auth'/> <query xmlns='jabber:iq:auth'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Returns Authentication Fields to Client'><![CDATA[ <example caption='Server Returns Authentication Fields to Client'><![CDATA[
<iq type='result' id='auth1'> <iq type='result' id='auth1'>
<query xmlns='jabber:iq:auth'> <query xmlns='jabber:iq:auth'>
@ -195,7 +195,7 @@
<resource/> <resource/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in <cite>RFC 6120</cite>), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a &lt;policy-violation/&gt; stream error (see <cite>RFC 6120</cite> regarding stream error syntax).</p> <p>If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in <cite>RFC 6120</cite>), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a &lt;policy-violation/&gt; stream error (see <cite>RFC 6120</cite> regarding stream error syntax).</p>
<p>Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in <cite>RFC 6120</cite> (e.g., to enable the server to provide the resource). The &lt;username/&gt; and &lt;resource/&gt; elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.</p> <p>Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in <cite>RFC 6120</cite> (e.g., to enable the server to provide the resource). The &lt;username/&gt; and &lt;resource/&gt; elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.</p>
<p>The foregoing stanza shows that the server supports both plaintext authentication (via the &lt;password/&gt; element) and digest authentication with SHA1-encrypted passwords (via the &lt;digest/&gt; element).</p> <p>The foregoing stanza shows that the server supports both plaintext authentication (via the &lt;password/&gt; element) and digest authentication with SHA1-encrypted passwords (via the &lt;digest/&gt; element).</p>
@ -208,7 +208,7 @@
<resource>globe</resource> <resource>globe</resource>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 6120</cite>, i.e., UTF-8 as defined in &rfc3269;).</p> <p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 6120</cite>, i.e., UTF-8 as defined in &rfc3269;).</p>
<p>The value of the &lt;digest/&gt; element MUST be computed according to the following algorithm:</p> <p>The value of the &lt;digest/&gt; element MUST be computed according to the following algorithm:</p>
<ol> <ol>
@ -225,12 +225,12 @@
<resource>globe</resource> <resource>globe</resource>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The character data shown in the &lt;digest/&gt; element is the output produced as a result of following the algorithm defined above when the stream ID is '3EE948B0' and the password is 'Calli0pe'.</p> <p>The character data shown in the &lt;digest/&gt; element is the output produced as a result of following the algorithm defined above when the stream ID is '3EE948B0' and the password is 'Calli0pe'.</p>
<p>If the credentials provided match those known by the server, the client will be successfully authenticated.</p> <p>If the credentials provided match those known by the server, the client will be successfully authenticated.</p>
<example caption='Server Informs Client of Successful Authentication'><![CDATA[ <example caption='Server Informs Client of Successful Authentication'><![CDATA[
<iq type='result' id='auth2'/> <iq type='result' id='auth2'/>
]]></example> ]]></example>
<p>Alternatively, authentication may fail. Possible causes of failure include:</p> <p>Alternatively, authentication may fail. Possible causes of failure include:</p>
<ol> <ol>
<li>The user provided incorrect credentials.</li> <li>The user provided incorrect credentials.</li>
@ -244,21 +244,21 @@
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Informs Client of Failed Authentication (Resource Conflict)'><![CDATA[ <example caption='Server Informs Client of Failed Authentication (Resource Conflict)'><![CDATA[
<iq type='error' id='auth2'> <iq type='error' id='auth2'>
<error code='409' type='cancel'> <error code='409' type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Informs Client of Failed Authentication (Required Information Not Provided)'><![CDATA[ <example caption='Server Informs Client of Failed Authentication (Required Information Not Provided)'><![CDATA[
<iq type='error' id='auth2'> <iq type='error' id='auth2'>
<error code='406' type='modify'> <error code='406' type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Stream Feature' anchor='streamfeature'> <section1 topic='Stream Feature' anchor='streamfeature'>
@ -271,7 +271,7 @@
</mechanisms> </mechanisms>
<auth xmlns='http://jabber.org/features/iq-auth'/> <auth xmlns='http://jabber.org/features/iq-auth'/>
</stream:features> </stream:features>
]]></example> ]]></example>
<p>A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p> <p>A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>
</section1> </section1>
<section1 topic='Error Handling' anchor='errors'> <section1 topic='Error Handling' anchor='errors'>
@ -333,7 +333,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Stream Feature' anchor='schemas-stream'> <section2 topic='Stream Feature' anchor='schemas-stream'>
<code><![CDATA[ <code><![CDATA[
@ -367,7 +367,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

66
xep-0079.xml
View File

@ -175,7 +175,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery information response"><![CDATA[ <example caption="Service Discovery information response"><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster' to='northumberland@shakespeare.lit/westminster'
@ -187,7 +187,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>A server SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity needs to determine whether the server supports individual actions and conditions, it SHOULD send a service discovery information request to that node; the server then MUST either return the list of supported actions and conditions or return an error such as &feature;. (Note: If the server does not provide information for this disco node, the requesting entity MUST assume that all actions and conditons are supported for each reported action set or condition set.)</p> <p>A server SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity needs to determine whether the server supports individual actions and conditions, it SHOULD send a service discovery information request to that node; the server then MUST either return the list of supported actions and conditions or return an error such as &feature;. (Note: If the server does not provide information for this disco node, the requesting entity MUST assume that all actions and conditons are supported for each reported action set or condition set.)</p>
<p>Each supported action shall be reported as a feature using the following format:</p> <p>Each supported action shall be reported as a feature using the following format:</p>
<code>http://jabber.org/protocol/amp?action={action}</code> <code>http://jabber.org/protocol/amp?action={action}</code>
@ -201,7 +201,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/amp'/> node='http://jabber.org/protocol/amp'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Response for individual actions and conditions"><![CDATA[ <example caption="Response for individual actions and conditions"><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster' to='northumberland@shakespeare.lit/westminster'
@ -220,7 +220,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Specifying Semantics' anchor='process-s2s-semantics'> <section3 topic='Specifying Semantics' anchor='process-s2s-semantics'>
<p>Once support is determined, the sender can attach the desired delivery semantics to the message:</p> <p>Once support is determined, the sender can attach the desired delivery semantics to the message:</p>
@ -236,7 +236,7 @@
value='2004-01-01T00:00:00Z'/> value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>The semantics are defined as a set of &lt;rule/&gt; elements within the &lt;amp/&gt; root element. Each &lt;rule/&gt; declares the condition to trigger on and the action to execute if triggered.</p> <p>The semantics are defined as a set of &lt;rule/&gt; elements within the &lt;amp/&gt; root element. Each &lt;rule/&gt; declares the condition to trigger on and the action to execute if triggered.</p>
<p>By default, the ruleset applies only to the "edge servers": those servers to which the sending and receiving entities are connected. (Note: For the purposes of Advanced Message Processing, "server" is defined as in <cite>XMPP Core</cite> and does not include any internal components, such as connection managers, that may provide functionality within a server implementation or installation.)</p> <p>By default, the ruleset applies only to the "edge servers": those servers to which the sending and receiving entities are connected. (Note: For the purposes of Advanced Message Processing, "server" is defined as in <cite>XMPP Core</cite> and does not include any internal components, such as connection managers, that may provide functionality within a server implementation or installation.)</p>
<p>The ruleset MAY be applied to all server-to-server "hops" along the route from the sending and receiving entities by adding the "per-hop' attribute to the &lt;amp/&gt; element. The value of this attribute is either "true" (apply rules to all hops) or "false" (follow default behavior, i.e., apply rules at the edge servers only).</p> <p>The ruleset MAY be applied to all server-to-server "hops" along the route from the sending and receiving entities by adding the "per-hop' attribute to the &lt;amp/&gt; element. The value of this attribute is either "true" (apply rules to all hops) or "false" (follow default behavior, i.e., apply rules at the edge servers only).</p>
@ -253,7 +253,7 @@
value='2004-01-01T00:00:00Z'/> value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>For examples of validation failure, refer to the <link url="#errors">Error Handling</link> section of this document.</p> <p>For examples of validation failure, refer to the <link url="#errors">Error Handling</link> section of this document.</p>
<p>Note: Even if "per-hop" processing is requested, each server in the route MUST ignore rules that cannot apply to it; the <link url="#conditions-def">Defined Conditions</link> outline if they can be applied per-hop.</p> <p>Note: Even if "per-hop" processing is requested, each server in the route MUST ignore rules that cannot apply to it; the <link url="#conditions-def">Defined Conditions</link> outline if they can be applied per-hop.</p>
</section3> </section3>
@ -420,7 +420,7 @@
<rule action='alert' condition='deliver' value='stored'/> <rule action='alert' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='drop' anchor='actions-def-drop'> <section3 topic='drop' anchor='actions-def-drop'>
<p>The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.</p> <p>The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.</p>
@ -445,7 +445,7 @@
</failed-rules> </failed-rules>
</error> </error>
</message> </message>
]]></example> ]]></example>
<p>Note that the error SHOULD be of type "modify", and the general error condition SHOULD be &lt;undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/&gt;.</p> <p>Note that the error SHOULD be of type "modify", and the general error condition SHOULD be &lt;undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/&gt;.</p>
</section3> </section3>
<section3 topic='notify' anchor='actions-def-notify'> <section3 topic='notify' anchor='actions-def-notify'>
@ -461,7 +461,7 @@
<rule action='notify' condition='deliver' value='stored'/> <rule action='notify' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Description of Condition/Action Combinations' anchor='description'> <section2 topic='Description of Condition/Action Combinations' anchor='description'>
@ -707,7 +707,7 @@
<rule action='error' condition='match-resource' value='other'/> <rule action='error' condition='match-resource' value='other'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>In the above case, the sender would receive an error reply if the message could not be delivered specifically to "francisco@hamlet.lit/pda" by the specified time. For example, if the intended resource went offline before the message could be delivered, the processing server would return the following error:</p> <p>In the above case, the sender would receive an error reply if the message could not be delivered specifically to "francisco@hamlet.lit/pda" by the specified time. For example, if the intended resource went offline before the message could be delivered, the processing server would return the following error:</p>
<example caption='Failed reliable data transport message'><![CDATA[ <example caption='Failed reliable data transport message'><![CDATA[
<message from='hamlet.lit' <message from='hamlet.lit'
@ -725,7 +725,7 @@
</failed-rules> </failed-rules>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Time-Sensitive Messages' anchor='examples-time'> <section2 topic='Time-Sensitive Messages' anchor='examples-time'>
<p>Time-sensitive messages are a frequent occurrence in some environments (e.g., front-office personnel routinely notify others of "events" such as guests, unexpected refreshments, and ad-hoc gatherings). To send a time-sensitive message, the sending entity includes a &lt;rule action='drop' condition='expire-at'/&gt; with the time when the event is to occur:</p> <p>Time-sensitive messages are a frequent occurrence in some environments (e.g., front-office personnel routinely notify others of "events" such as guests, unexpected refreshments, and ad-hoc gatherings). To send a time-sensitive message, the sending entity includes a &lt;rule action='drop' condition='expire-at'/&gt; with the time when the event is to occur:</p>
@ -742,7 +742,7 @@
<rule action='drop' condition='expire-at' value='2003-06-23T23:00:00Z'/> <rule action='drop' condition='expire-at' value='2003-06-23T23:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>In the above case, the server for "linuxwolf@outer-planes.net" would not deliver the message once 23:00 UTC (3:00 PM Pacific Daylight Time) has passed.</p> <p>In the above case, the server for "linuxwolf@outer-planes.net" would not deliver the message once 23:00 UTC (3:00 PM Pacific Daylight Time) has passed.</p>
</section2> </section2>
<section2 topic='Transient Messages' anchor='examples-transient'> <section2 topic='Transient Messages' anchor='examples-transient'>
@ -757,7 +757,7 @@
<rule action='drop' condition='deliver' value='stored'/> <rule action='drop' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>Alternatively, the sending entity includes a &lt;rule action='alert' condition='deliver' value='stored'/&gt; to be alerted instead of having the message silently dropped:</p> <p>Alternatively, the sending entity includes a &lt;rule action='alert' condition='deliver' value='stored'/&gt; to be alerted instead of having the message silently dropped:</p>
<example caption='Sending a transient message (requesting alert)'><![CDATA[ <example caption='Sending a transient message (requesting alert)'><![CDATA[
<message to='francisco@hamlet.lit' <message to='francisco@hamlet.lit'
@ -769,7 +769,7 @@
<rule action='alert' condition='deliver' value='stored'/> <rule action='alert' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='Sender alerted regarding transient message'><![CDATA[ <example caption='Sender alerted regarding transient message'><![CDATA[
<message from='hamlet.lit' <message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore' to='bernardo@hamlet.lit/elsinore'
@ -781,7 +781,7 @@
<rule action='alert' condition='deliver' value='stored'/> <rule action='alert' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Error Handling' anchor='errors'> <section1 topic='Error Handling' anchor='errors'>
@ -858,7 +858,7 @@
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/> <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='Server does not support action'><![CDATA[ <example caption='Server does not support action'><![CDATA[
<message <message
from='shakespeare.lit' from='shakespeare.lit'
@ -877,7 +877,7 @@
</unsupported-actions> </unsupported-actions>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Unsupported Condition' anchor='errors-condition'> <section3 topic='Unsupported Condition' anchor='errors-condition'>
<example caption='A message with AMP semantics'><![CDATA[ <example caption='A message with AMP semantics'><![CDATA[
@ -890,7 +890,7 @@
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/> <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='Server does not support condition'><![CDATA[ <example caption='Server does not support condition'><![CDATA[
<message <message
from='shakespeare.lit' from='shakespeare.lit'
@ -907,7 +907,7 @@
</unsupported-conditions> </unsupported-conditions>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Not Acceptable' anchor='errors-notacceptable'> <section3 topic='Not Acceptable' anchor='errors-notacceptable'>
<example caption='A message with AMP semantics'><![CDATA[ <example caption='A message with AMP semantics'><![CDATA[
@ -920,7 +920,7 @@
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/> <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='The rule is not acceptable to the server'><![CDATA[ <example caption='The rule is not acceptable to the server'><![CDATA[
<message <message
from='shakespeare.lit' from='shakespeare.lit'
@ -937,7 +937,7 @@
</invalid-rules> </invalid-rules>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Service Unavailable' anchor='errors-unavail'> <section3 topic='Service Unavailable' anchor='errors-unavail'>
<example caption='A message with AMP semantics'><![CDATA[ <example caption='A message with AMP semantics'><![CDATA[
@ -950,7 +950,7 @@
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/> <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='AMP service is unavailable'><![CDATA[ <example caption='AMP service is unavailable'><![CDATA[
<message <message
from='royalty.england.lit' from='royalty.england.lit'
@ -964,7 +964,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Undefined Condition' anchor='errors-undefined'> <section3 topic='Undefined Condition' anchor='errors-undefined'>
<example caption='A message with AMP semantics'><![CDATA[ <example caption='A message with AMP semantics'><![CDATA[
@ -979,7 +979,7 @@
<rule action='error' condition='deliver' value='stored'/> <rule action='error' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<example caption='Failed rules'><![CDATA[ <example caption='Failed rules'><![CDATA[
<message from='hamlet.lit' <message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore' to='bernardo@hamlet.lit/elsinore'
@ -998,7 +998,7 @@
</failed-rules> </failed-rules>
</error> </error>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -1011,7 +1011,7 @@
<stream:features> <stream:features>
<amp xmlns='http://jabber.org/features/amp'/> <amp xmlns='http://jabber.org/features/amp'/>
</stream:features> </stream:features>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>Most AMP conditions could be used by unauthorized individuals to gain access to presence information about users of IM servers and other presence-based messaging systems. For example, consider the following scenario: the user &lt;romeo@montague.net&gt; is not an authorized subscriber to the presence of the user &lt;nurse@capulet.com&gt;, but sends a &MESSAGE; stanza with a "deliver" rule of "stored" and an action of "alert" to that address; if the Nurse is not online, Romeo would receive an AMP alert that the message has been stored offline, in the process discovering that the Nurse is offline. Similar scenarios are possible with the "match-resource" rule (send to the user's usual resource) and the "expire-at" rule (send messages every minute to poll for presence). If a server implements presence subscriptions as specified in &rfc3921;, it SHOULD NOT return alerts, errors, or other AMP notifications to senders who are not authorized to view the recipient's presence information (via a subscription of "both" or "from") if the notification would reveal the recipient's status as online or offline. <note>An exception might be fully-trusted or closed networks.</note> <p>Most AMP conditions could be used by unauthorized individuals to gain access to presence information about users of IM servers and other presence-based messaging systems. For example, consider the following scenario: the user &lt;romeo@montague.net&gt; is not an authorized subscriber to the presence of the user &lt;nurse@capulet.com&gt;, but sends a &MESSAGE; stanza with a "deliver" rule of "stored" and an action of "alert" to that address; if the Nurse is not online, Romeo would receive an AMP alert that the message has been stored offline, in the process discovering that the Nurse is offline. Similar scenarios are possible with the "match-resource" rule (send to the user's usual resource) and the "expire-at" rule (send messages every minute to poll for presence). If a server implements presence subscriptions as specified in &rfc3921;, it SHOULD NOT return alerts, errors, or other AMP notifications to senders who are not authorized to view the recipient's presence information (via a subscription of "both" or "from") if the notification would reveal the recipient's status as online or offline. <note>An exception might be fully-trusted or closed networks.</note>
@ -1053,7 +1053,7 @@
<processing>values that result in message processing</processing> <processing>values that result in message processing</processing>
<doc>the document (e.g., XEP) in which this condition is specified</doc> <doc>the document (e.g., XEP) in which this condition is specified</doc>
</condition> </condition>
]]></code> ]]></code>
<p>The registrant may register more than one condition at a time, each contained in a separate &lt;condition/&gt; element.</p> <p>The registrant may register more than one condition at a time, each contained in a separate &lt;condition/&gt; element.</p>
<p>Note: The namespace for the condition set shall be included in the Service Discovery features registry.</p> <p>Note: The namespace for the condition set shall be included in the Service Discovery features registry.</p>
</section4> </section4>
@ -1104,7 +1104,7 @@
</processing> </processing>
<doc>XEP-0079</doc> <doc>XEP-0079</doc>
</condition> </condition>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
<section3 topic='Rule Actions Registry' anchor='registrar-reg-actions'> <section3 topic='Rule Actions Registry' anchor='registrar-reg-actions'>
@ -1118,7 +1118,7 @@
<behavior>the expected behavior if the rule is triggered</behavior> <behavior>the expected behavior if the rule is triggered</behavior>
<doc>the document (e.g., XEP) in which this action is specified</doc> <doc>the document (e.g., XEP) in which this action is specified</doc>
</action> </action>
]]></code> ]]></code>
<p>The registrant may register more than one action at a time, each contained in a separate &lt;action/&gt; element.</p> <p>The registrant may register more than one action at a time, each contained in a separate &lt;action/&gt; element.</p>
<p>Note: The namespace for the action set shall be included in the Service Discovery features registry.</p> <p>Note: The namespace for the action set shall be included in the Service Discovery features registry.</p>
</section4> </section4>
@ -1162,7 +1162,7 @@
</behavior> </behavior>
<doc>XEP-0079</doc> <doc>XEP-0079</doc>
</action> </action>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
</section2> </section2>
@ -1230,7 +1230,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Errors' anchor='schemas-err'> <section2 topic='Errors' anchor='schemas-err'>
<code><![CDATA[ <code><![CDATA[
@ -1266,7 +1266,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Stream Feature' anchor='schemas-streams'> <section2 topic='Stream Feature' anchor='schemas-streams'>
<code><![CDATA[ <code><![CDATA[
@ -1294,7 +1294,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>

10
xep-0080.xml
View File

@ -335,7 +335,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Subscriber receives event with payload'><![CDATA[ <example caption='Subscriber receives event with payload'><![CDATA[
<message from='portia@merchantofvenice.lit' <message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'> to='bassanio@merchantofvenice.lit'>
@ -353,7 +353,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>In order to indicate that the user is no longer publishing any location information, the user's client shall send an empty &lt;geoloc/&gt; element, which can be considered a "stop command" for geolocation:</p> <p>In order to indicate that the user is no longer publishing any location information, the user's client shall send an empty &lt;geoloc/&gt; element, which can be considered a "stop command" for geolocation:</p>
<example caption='User stops publishing geolocation information'><![CDATA[ <example caption='User stops publishing geolocation information'><![CDATA[
<iq from='portia@merchantofvenice.lit/pda' <iq from='portia@merchantofvenice.lit/pda'
@ -367,7 +367,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Subscriber receives empty event'><![CDATA[ <example caption='Subscriber receives empty event'><![CDATA[
<message from='portia@merchantofvenice.lit' <message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'> to='bassanio@merchantofvenice.lit'>
@ -379,7 +379,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -558,6 +558,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

22
xep-0081.xml
View File

@ -90,7 +90,7 @@
<jabber> <jabber>
<message jid='stpeter@jabber.org'/> <message jid='stpeter@jabber.org'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a single message to the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='normal' as specified in &xmppim;, first authenticating with the user's Jabber/XMPP server if necessary.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a single message to the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='normal' as specified in &xmppim;, first authenticating with the user's Jabber/XMPP server if necessary.</p>
</section2> </section2>
<section2 topic='Starting a Chat' anchor='chat'> <section2 topic='Starting a Chat' anchor='chat'>
@ -99,7 +99,7 @@
<jabber> <jabber>
<chat jid='stpeter@jabber.org'/> <chat jid='stpeter@jabber.org'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for chatting with the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='chat' as specified in <cite>XMPP IM</cite>, first authenticating with the user's Jabber/XMPP server if necessary.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for chatting with the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='chat' as specified in <cite>XMPP IM</cite>, first authenticating with the user's Jabber/XMPP server if necessary.</p>
</section2> </section2>
<section2 topic='Subscribing to Presence' anchor='subscribe'> <section2 topic='Subscribing to Presence' anchor='subscribe'>
@ -108,7 +108,7 @@
<jabber> <jabber>
<subscribe jid='stpeter@jabber.org'/> <subscribe jid='stpeter@jabber.org'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a presence subscription request to the JID defined in the file (e.g., specifying a name and/or group for the contact). If the user completes the interface, the helper application shall then send a presence stanza of type='subscribe' as specified in <cite>XMPP IM</cite>, first authenticating with the user's Jabber/XMPP server if necessary. The helper application SHOULD perform a "roster set" before sending the presence subscription request, as described in <cite>XMPP IM</cite>.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a presence subscription request to the JID defined in the file (e.g., specifying a name and/or group for the contact). If the user completes the interface, the helper application shall then send a presence stanza of type='subscribe' as specified in <cite>XMPP IM</cite>, first authenticating with the user's Jabber/XMPP server if necessary. The helper application SHOULD perform a "roster set" before sending the presence subscription request, as described in <cite>XMPP IM</cite>.</p>
</section2> </section2>
<section2 topic='Joining a Groupchat Room' anchor='groupchat'> <section2 topic='Joining a Groupchat Room' anchor='groupchat'>
@ -117,7 +117,7 @@
<jabber> <jabber>
<groupchat jid='jdev@conference.jabber.org'/> <groupchat jid='jdev@conference.jabber.org'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.</p>
</section2> </section2>
<section2 topic='Registering with a Service' anchor='register'> <section2 topic='Registering with a Service' anchor='register'>
@ -126,7 +126,7 @@
<jabber> <jabber>
<register jid='headlines.shakespeare.lit'/> <register jid='headlines.shakespeare.lit'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in <cite>XEP-0077</cite>.</p> <p>The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in <cite>XEP-0077</cite>.</p>
</section2> </section2>
<!-- <!--
@ -139,7 +139,7 @@
<info/> <info/>
</disco> </disco>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a service discovery request to the JID defined in the file.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a service discovery request to the JID defined in the file.</p>
</section2> </section2>
<section2 topic='Searching a Directory' anchor='search'> <section2 topic='Searching a Directory' anchor='search'>
@ -150,7 +150,7 @@
<nick>stpeter</nick> <nick>stpeter</nick>
</search> </search>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for searching the directory associated with the JID defined in the file, including pre-populated information as specified (e.g., nick, first name, last name).</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for searching the directory associated with the JID defined in the file, including pre-populated information as specified (e.g., nick, first name, last name).</p>
</section2> </section2>
<section2 topic='Requesting a vCard' anchor='vcard'> <section2 topic='Requesting a vCard' anchor='vcard'>
@ -159,7 +159,7 @@
<jabber> <jabber>
<vcard jid='stpeter@jabber.org'/> <vcard jid='stpeter@jabber.org'/>
</jabber> </jabber>
]]></code> ]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for requesting the vCard of the JID defined in the file.</p> <p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for requesting the vCard of the JID defined in the file.</p>
</section2> </section2>
--> -->
@ -179,7 +179,7 @@
<resource>Work</resource> <resource>Work</resource>
</authenticate> </authenticate>
</connect> </connect>
]]></code> ]]></code>
<p>The username, password, and resource are not required if there is some other extension inside authenticate, that, e.g. does SSO. Authenticate is mostly useful only for these SSO situations, anyway. If the user is already connected, the application SHOULD ignore the &lt;connect/&gt; block.</p> <p>The username, password, and resource are not required if there is some other extension inside authenticate, that, e.g. does SSO. Authenticate is mostly useful only for these SSO situations, anyway. If the user is already connected, the application SHOULD ignore the &lt;connect/&gt; block.</p>
</section1> </section1>
--> -->
@ -219,7 +219,7 @@ Person and email address to contact for further information:
XMPP Registrar, <registrar@xmpp.org> XMPP Registrar, <registrar@xmpp.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: XSF, XMPP Registrar Author/Change controller: XSF, XMPP Registrar
]]></code> ]]></code>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
@ -259,7 +259,7 @@ Author/Change controller: XSF, XMPP Registrar
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Open Issues'> <section1 topic='Open Issues'>
<ol> <ol>

6
xep-0083.xml
View File

@ -73,7 +73,7 @@ SERVER:
<roster xmlns='roster:delimiter'>::</roster> <roster xmlns='roster:delimiter'>::</roster>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Retrieving the Roster' anchor='usecases-retrieve'> <section2 topic='Retrieving the Roster' anchor='usecases-retrieve'>
<p>Now that the client has a delimiter, we can retrieve and parse the roster properly.</p> <p>Now that the client has a delimiter, we can retrieve and parse the roster properly.</p>
@ -116,7 +116,7 @@ SERVER:
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Bottom, Quince and Snug should be grouped together in a group 'Actors' underneath the group 'Midsummer'. Theseus and Hippolyta should be grouped together in a group 'Royalty' under 'Midsummer'. Robin Goodfellow, meanwhile, being in a class unto himself, is a plain contact under the 'Midsummer' group rather than in an actual sub-group. The group Hamlet, containing only one melancholy prince and his mother, contains no sub-groups at all.</p> <p>Bottom, Quince and Snug should be grouped together in a group 'Actors' underneath the group 'Midsummer'. Theseus and Hippolyta should be grouped together in a group 'Royalty' under 'Midsummer'. Robin Goodfellow, meanwhile, being in a class unto himself, is a plain contact under the 'Midsummer' group rather than in an actual sub-group. The group Hamlet, containing only one melancholy prince and his mother, contains no sub-groups at all.</p>
<p>As should be apparent, a client which does not support the delimiter will instead create a separate group -- such as 'Midsummer::Actors' -- and thus will still have each set of contacts grouped with the other appropriate contacts.</p> <p>As should be apparent, a client which does not support the delimiter will instead create a separate group -- such as 'Midsummer::Actors' -- and thus will still have each set of contacts grouped with the other appropriate contacts.</p>
</section2> </section2>
@ -151,6 +151,6 @@ SERVER:
<xs:element name='roster' type='xs:string'/> <xs:element name='roster' type='xs:string'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

36
xep-0084.xml
View File

@ -176,10 +176,10 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Pubsub service replies with success'><![CDATA[ <example caption='Pubsub service replies with success'><![CDATA[
<iq type='result' to='juliet@capulet.lit/chamber' id='publish1'/> <iq type='result' to='juliet@capulet.lit/chamber' id='publish1'/>
]]></example> ]]></example>
<p>If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to <cite>RFC 2616</cite>).</p> <p>If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to <cite>RFC 2616</cite>).</p>
</section2> </section2>
<section2 topic='User Publishes Metadata Notification' anchor='process-pubmeta'> <section2 topic='User Publishes Metadata Notification' anchor='process-pubmeta'>
@ -201,7 +201,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The following example shows metadata specifying avatar data that is available at an HTTP URL.</p> <p>The following example shows metadata specifying avatar data that is available at an HTTP URL.</p>
<example caption='Publishing avatar metadata'><![CDATA[ <example caption='Publishing avatar metadata'><![CDATA[
<iq type='set' from='juliet@capulet.lit/chamber' id='publish2'> <iq type='set' from='juliet@capulet.lit/chamber' id='publish2'>
@ -220,7 +220,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Subscribers Receive Metadata Notification' anchor='process-subnotify'> <section2 topic='Subscribers Receive Metadata Notification' anchor='process-subnotify'>
<p>The user's virtual pubsub service would then send the metadata notification to entities that have subscribed to the user's metadata node or contacts who have advertised an interest in receiving avatar metadata by including a &xep0115; feature of "urn:xmpp:avatar:metadata+notify".</p> <p>The user's virtual pubsub service would then send the metadata notification to entities that have subscribed to the user's metadata node or contacts who have advertised an interest in receiving avatar metadata by including a &xep0115; feature of "urn:xmpp:avatar:metadata+notify".</p>
@ -243,7 +243,7 @@
<address type='replyto' jid='juliet@capulet.lit/chamber'/> <address type='replyto' jid='juliet@capulet.lit/chamber'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<p>As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see <cite>XEP-0060</cite> for details).</p> <p>As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see <cite>XEP-0060</cite> for details).</p>
</section2> </section2>
<section2 topic='Subscribers Retrieve Data' anchor='process-subretrieve'> <section2 topic='Subscribers Retrieve Data' anchor='process-subretrieve'>
@ -260,7 +260,7 @@
</items> </items>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The PEP service running at the user's server then SHOULD return the avatar data.</p> <p>The PEP service running at the user's server then SHOULD return the avatar data.</p>
<example caption='PEP service returns avatar data'><![CDATA[ <example caption='PEP service returns avatar data'><![CDATA[
<iq type='result' <iq type='result'
@ -277,7 +277,7 @@
</items> </items>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>If the &lt;info/&gt; element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see <cite>RFC 2616</cite>).</p> <p>If the &lt;info/&gt; element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see <cite>RFC 2616</cite>).</p>
</section2> </section2>
<section2 topic='Publisher Disables Avatar Publishing' anchor='pub-disable'> <section2 topic='Publisher Disables Avatar Publishing' anchor='pub-disable'>
@ -292,7 +292,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>As before, subscribers to the metadata node would then receive the notification.</p> <p>As before, subscribers to the metadata node would then receive the notification.</p>
<example caption='Subscribers receive avatar metadata notification'><![CDATA[ <example caption='Subscribers receive avatar metadata notification'><![CDATA[
<message to='romeo@montague.lit/home' from='juliet@capulet.lit'> <message to='romeo@montague.lit/home' from='juliet@capulet.lit'>
@ -304,7 +304,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>Note: In an earlier version of this specification, the user indicated that it wanted to disable publishing by sending a &lt;metadata/&gt; element containing a &lt;stop/&gt; child element. For consistency with other PEP payload formats, support for the &lt;stop/&gt; element is <em>deprecated</em>.</p> <p>Note: In an earlier version of this specification, the user indicated that it wanted to disable publishing by sending a &lt;metadata/&gt; element containing a &lt;stop/&gt; child element. For consistency with other PEP payload formats, support for the &lt;stop/&gt; element is <em>deprecated</em>.</p>
</section2> </section2>
</section1> </section1>
@ -321,7 +321,7 @@
<data xmlns='urn:xmpp:avatar:data'> <data xmlns='urn:xmpp:avatar:data'>
IMAGE DATA IMAGE DATA
</data> </data>
]]></code> ]]></code>
<p>The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of &rfc4648;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)</p> <p>The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of &rfc4648;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)</p>
<p>The &lt;data/&gt; element MUST NOT possess any attributes.</p> <p>The &lt;data/&gt; element MUST NOT possess any attributes.</p>
<p>Support for the &lt;data/&gt; element is REQUIRED.</p> <p>Support for the &lt;data/&gt; element is REQUIRED.</p>
@ -345,7 +345,7 @@
url='HTTP-URL-for-image-data' url='HTTP-URL-for-image-data'
width='image-width-in-pixels'/> width='image-width-in-pixels'/>
</metadata> </metadata>
]]></code> ]]></code>
<p>The &lt;info/&gt; child element MUST be empty.</p> <p>The &lt;info/&gt; child element MUST be empty.</p>
<p>The defined attributes of the &lt;info/&gt; element are specified in the following table.</p> <p>The defined attributes of the &lt;info/&gt; element are specified in the following table.</p>
<table caption='Info Attributes'> <table caption='Info Attributes'>
@ -395,7 +395,7 @@
... APPLICATION-SPECIFIC DATA ... ... APPLICATION-SPECIFIC DATA ...
</pointer> </pointer>
</metadata> </metadata>
]]></code> ]]></code>
<p>The &lt;pointer/&gt; element MAY possess the following attributes if the publishing application has the relevant information:</p> <p>The &lt;pointer/&gt; element MAY possess the following attributes if the publishing application has the relevant information:</p>
<ul> <ul>
<li><em>bytes</em> -- The size of the image data in bytes.</li> <li><em>bytes</em> -- The size of the image data in bytes.</li>
@ -447,7 +447,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>In the foregoing example, the image encapsulated in the "image/png" content type is available both at a pubsub data node and at an HTTP URL; therefore it is included twice (the second time with a 'url' attribute).</p> <p>In the foregoing example, the image encapsulated in the "image/png" content type is available both at a pubsub data node and at an HTTP URL; therefore it is included twice (the second time with a 'url' attribute).</p>
</section2> </section2>
<section2 topic='Metadata With Pointer' anchor='examples-pointer'> <section2 topic='Metadata With Pointer' anchor='examples-pointer'>
@ -474,7 +474,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Service Discovery' anchor='disco'> <section1 topic='Service Discovery' anchor='disco'>
@ -487,7 +487,7 @@
id='items1'> id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items.</p> <p>If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items.</p>
<example caption='Disco items result'><![CDATA[ <example caption='Disco items result'><![CDATA[
<iq type='result' <iq type='result'
@ -499,7 +499,7 @@
<item jid='juliet@capulet.lit' node='urn:xmpp:avatar:metadata'/> <item jid='juliet@capulet.lit' node='urn:xmpp:avatar:metadata'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The contact then MAY subscribe to the metadata node following the protocol specified in <cite>XEP-0060</cite>. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).</p> <p>The contact then MAY subscribe to the metadata node following the protocol specified in <cite>XEP-0060</cite>. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).</p>
</section2> </section2>
</section1> </section1>
@ -549,7 +549,7 @@
<xs:element name='data' type='xs:base64Binary'/> <xs:element name='data' type='xs:base64Binary'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Metadata Namespace' anchor='schema-metadata'> <section2 topic='Metadata Namespace' anchor='schema-metadata'>
<code><![CDATA[ <code><![CDATA[
@ -609,7 +609,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='Author Note' anchor='authornote'>

44
xep-0085.xml
View File

@ -206,7 +206,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
| | | |
| | | |
+---<---<---<---<---<---<---<---<---<---+ +---<---<---<---<---<---<---<---<---<---+
]]></code> ]]></code>
<p>Note: Other transitions are not forbidden if the developers of an implementation feel that such transitions are desirable (e.g., INACTIVE to PAUSED if a user returns to a chat session interface containing an unfinished message).</p> <p>Note: Other transitions are not forbidden if the developers of an implementation feel that such transitions are desirable (e.g., INACTIVE to PAUSED if a user returns to a chat session interface containing an unfinished message).</p>
</section1> </section1>
<section1 topic='Determining Support' anchor='support'> <section1 topic='Determining Support' anchor='support'>
@ -218,7 +218,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
id='disco1' id='disco1'
@ -228,7 +228,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<feature var='http://jabber.org/protocol/chatstates'/> <feature var='http://jabber.org/protocol/chatstates'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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>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>
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
@ -321,7 +321,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<body>Who's there?</body> <body>Who's there?</body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[ <example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message <message
from='francisco@shakespeare.lit/elsinore' from='francisco@shakespeare.lit/elsinore'
@ -330,7 +330,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<body>Nay, answer me: stand, and unfold yourself.</body> <body>Nay, answer me: stand, and unfold yourself.</body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>Because the User now knows that the Contact supports chat state notifications, the User can send other notification types.</p> <p>Because the User now knows that the Contact supports chat state notifications, the User can send other notification types.</p>
<example caption="User Sends Standalone &lt;composing/&gt; Notification"><![CDATA[ <example caption="User Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
<message <message
@ -339,7 +339,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
type='chat'> type='chat'>
<composing xmlns='http://jabber.org/protocol/chatstates'/> <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<example caption="User Sends a Content Message Reply With &lt;active/&gt; Notification"><![CDATA[ <example caption="User Sends a Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message <message
from='bernardo@shakespeare.lit/pda' from='bernardo@shakespeare.lit/pda'
@ -348,7 +348,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<body>Long live the king!</body> <body>Long live the king!</body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>And so forth.</p> <p>And so forth.</p>
</section1> </section1>
<section1 topic='A Detailed Conversation' anchor='example-detail'> <section1 topic='A Detailed Conversation' anchor='example-detail'>
@ -366,7 +366,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>At this point Juliet's client knows that Romeo's client supports chat state notifications. Thus she replies to the content message and her client includes a notification that her state is &lt;active/&gt;:</p> <p>At this point Juliet's client knows that Romeo's client supports chat state notifications. Thus she replies to the content message and her client includes a notification that her state is &lt;active/&gt;:</p>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[ <example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message <message
@ -380,7 +380,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>And so the conversation continues. After a while, Juliet asks a question that brings Romeo up short:</p> <p>And so the conversation continues. After a while, Juliet asks a question that brings Romeo up short:</p>
<example caption="Contact Sends Another Message"><![CDATA[ <example caption="Contact Sends Another Message"><![CDATA[
<message <message
@ -390,7 +390,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
]]></example> ]]></example>
<p>Romeo begins composing a reply to Juliet's heartfelt question, and his client notifies Juliet that he is composing a reply.</p> <p>Romeo begins composing a reply to Juliet's heartfelt question, and his client notifies Juliet that he is composing a reply.</p>
<example caption="User's Client Sends Standalone &lt;composing/&gt; Notification"><![CDATA[ <example caption="User's Client Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
<message <message
@ -400,7 +400,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<composing xmlns='http://jabber.org/protocol/chatstates'/> <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>Romeo realizes his reply is too rash and pauses to choose the right words; after some (configurable) time period, his client senses the delay and sends a state of &lt;paused/&gt;.</p> <p>Romeo realizes his reply is too rash and pauses to choose the right words; after some (configurable) time period, his client senses the delay and sends a state of &lt;paused/&gt;.</p>
<example caption="User's Client Sends Standalone &lt;paused/&gt; Notification"><![CDATA[ <example caption="User's Client Sends Standalone &lt;paused/&gt; Notification"><![CDATA[
<message <message
@ -410,7 +410,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<paused xmlns='http://jabber.org/protocol/chatstates'/> <paused xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>Romeo starts composing again, and his Jabber client sends a &lt;composing/&gt; notification to Juliet's client.</p> <p>Romeo starts composing again, and his Jabber client sends a &lt;composing/&gt; notification to Juliet's client.</p>
<example caption="User's Clients Sends Standalone &lt;composing/&gt; Notification"><![CDATA[ <example caption="User's Clients Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
<message <message
@ -420,7 +420,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<composing xmlns='http://jabber.org/protocol/chatstates'/> <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>Romeo finally sends his reply.</p> <p>Romeo finally sends his reply.</p>
<example caption="User Replies"><![CDATA[ <example caption="User Replies"><![CDATA[
<message <message
@ -431,7 +431,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>The conversation ebbs and flows, waxes and wanes, until Juliet is called away by her Nurse...</p> <p>The conversation ebbs and flows, waxes and wanes, until Juliet is called away by her Nurse...</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[ <example caption="Contact's Client Sends Content Message"><![CDATA[
<message <message
@ -446,7 +446,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>We suppose that Juliet minimizes the chat window, so her client generates an &lt;inactive/&gt; notification:</p> <p>We suppose that Juliet minimizes the chat window, so her client generates an &lt;inactive/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;inactive/&gt; Notification"><![CDATA[ <example caption="Contact's Client Sends Standalone &lt;inactive/&gt; Notification"><![CDATA[
<message <message
@ -456,7 +456,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<inactive xmlns='http://jabber.org/protocol/chatstates'/> <inactive xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>When she returns and brings the window up again, her client generates an &lt;active/&gt; notification:</p> <p>When she returns and brings the window up again, her client generates an &lt;active/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;active/&gt; Notification"><![CDATA[ <example caption="Contact's Client Sends Standalone &lt;active/&gt; Notification"><![CDATA[
<message <message
@ -466,7 +466,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>The conversation continues, but Juliet is called away again by that nagging Nurse:</p> <p>The conversation continues, but Juliet is called away again by that nagging Nurse:</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[ <example caption="Contact's Client Sends Content Message"><![CDATA[
<message <message
@ -479,7 +479,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>We suppose that Juliet closes the chat window, so her client generates a &lt;gone/&gt; notification:</p> <p>We suppose that Juliet closes the chat window, so her client generates a &lt;gone/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;gone/&gt; Notification"><![CDATA[ <example caption="Contact's Client Sends Standalone &lt;gone/&gt; Notification"><![CDATA[
<message <message
@ -489,7 +489,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<thread>act2scene2chat1</thread> <thread>act2scene2chat1</thread>
<gone xmlns='http://jabber.org/protocol/chatstates'/> <gone xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>Romeo's client now considers the chat thread to be over and generates a new Thread ID when he sends a new message:</p> <p>Romeo's client now considers the chat thread to be over and generates a new Thread ID when he sends a new message:</p>
<example caption="User's Client Sends Content Message with New Thread ID"><![CDATA[ <example caption="User's Client Sends Content Message with New Thread ID"><![CDATA[
<message <message
@ -504,7 +504,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>When Juliet returns to her computer on the balcony, she finds the new message from Romeo. When she finishes her reply, her client includes both an &lt;active/&gt; notification and the new Thread ID with the body of her reply:</p> <p>When Juliet returns to her computer on the balcony, she finds the new message from Romeo. When she finishes her reply, her client includes both an &lt;active/&gt; notification and the new Thread ID with the body of her reply:</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[ <example caption="Contact's Client Sends Content Message"><![CDATA[
<message <message
@ -517,7 +517,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</body> </body>
<active xmlns='http://jabber.org/protocol/chatstates'/> <active xmlns='http://jabber.org/protocol/chatstates'/>
</message> </message>
]]></example> ]]></example>
<p>And so forth.</p> <p>And so forth.</p>
<p>My, these star-crossed lovers do go on, don't they?</p> <p>My, these star-crossed lovers do go on, don't they?</p>
</section1> </section1>
@ -565,6 +565,6 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

26
xep-0087.xml
View File

@ -102,7 +102,7 @@
id='info1'> id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]> ]]>
</example> </example>
<p> <p>
The Receiver will advertise the "http://jabber.org/protocol/si" namespace as The Receiver will advertise the "http://jabber.org/protocol/si" namespace as
@ -123,7 +123,7 @@
<feature var='htpt://jabber.org/protocol/si/profile/filexfer'/> <feature var='htpt://jabber.org/protocol/si/profile/filexfer'/>
</query> </query>
</iq> </iq>
]]> ]]>
</example> </example>
<p> <p>
Now that the Sender is sure that the Receiver support Stream Initiation they Now that the Sender is sure that the Receiver support Stream Initiation they
@ -149,7 +149,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<!-- <!--
<example caption='Offer Stream Initiation (Profile in NS)'> <example caption='Offer Stream Initiation (Profile in NS)'>
@ -175,7 +175,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
--> -->
<!-- <!--
@ -193,7 +193,7 @@
<stream>jabber:iq:oob</stream> <stream>jabber:iq:oob</stream>
<stream>ibb</stream> <stream>ibb</stream>
</si> </si>
]]> ]]>
</example> </example>
--> -->
<p> <p>
@ -217,21 +217,21 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Rejecting Stream Initiation'> <example caption='Rejecting Stream Initiation'>
<![CDATA[ <![CDATA[
<iq type='error' to='sender@jabber.org/resource' id='offer1'> <iq type='error' to='sender@jabber.org/resource' id='offer1'>
<error code='403'>Offer Declined</error> <error code='403'>Offer Declined</error>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='No Valid Streams'> <example caption='No Valid Streams'>
<![CDATA[ <![CDATA[
<iq type='error' to='sender@jabber.org/resource' id='offer1'> <iq type='error' to='sender@jabber.org/resource' id='offer1'>
<error code='406'>No Valid Streams</error> <error code='406'>No Valid Streams</error>
</iq> </iq>
]]> ]]>
</example> </example>
<p> <p>
If the Receiver has accepted the Stream Initiation the Sender may then used If the Receiver has accepted the Stream Initiation the Sender may then used
@ -245,7 +245,7 @@
id='a0'> id='a0'>
<stream>s5b</stream> <stream>s5b</stream>
</si> </si>
]]> ]]>
</example> </example>
<example caption='Offer to Start a MP3 Stream'> <example caption='Offer to Start a MP3 Stream'>
<![CDATA[ <![CDATA[
@ -263,7 +263,7 @@
</x> </x>
</feature> </feature>
</si> </si>
]]> ]]>
</example> </example>
<example caption='Offer to Start a MP3 Stream (Alternate Stream Negotiation)'> <example caption='Offer to Start a MP3 Stream (Alternate Stream Negotiation)'>
<![CDATA[ <![CDATA[
@ -275,7 +275,7 @@
<stream>s5b</stream> <stream>s5b</stream>
<stream>ibb</stream> <stream>ibb</stream>
</si> </si>
]]> ]]>
</example> </example>
--> -->
</section1> </section1>
@ -332,7 +332,7 @@
<stream id='0' xmlns:si='http://jabber.org/protocol/si' si:id='si0'> <stream id='0' xmlns:si='http://jabber.org/protocol/si' si:id='si0'>
<start/> <start/>
</stream> </stream>
]]> ]]>
</code> </code>
</li> </li>
<li> <li>
@ -343,7 +343,7 @@
<start/> <start/>
<si xmlns='http://jabber.org/protocol/si' id='si0'/> <si xmlns='http://jabber.org/protocol/si' id='si0'/>
</stream> </stream>
]]> ]]>
</code> </code>
</li> </li>
</ul> </ul>

6
xep-0090.xml
View File

@ -68,7 +68,7 @@
id='time_1'> id='time_1'>
<query xmlns='jabber:iq:time'/> <query xmlns='jabber:iq:time'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='A Response to the Query'><![CDATA[ <example caption='A Response to the Query'><![CDATA[
<iq type='result' <iq type='result'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
@ -80,7 +80,7 @@
<display>Tue Sep 10 12:58:35 2002</display> <display>Tue Sep 10 12:58:35 2002</display>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p> <p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
</section1> </section1>
<section1 topic='A Note on Time Formats'> <section1 topic='A Note on Time Formats'>
@ -127,6 +127,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

8
xep-0091.xml
View File

@ -98,7 +98,7 @@
Offline Storage Offline Storage
</x> </x>
</message> </message>
]]></example> ]]></example>
<example caption='Receiving the Last Presence Update of Another Entity'><![CDATA[ <example caption='Receiving the Last Presence Update of Another Entity'><![CDATA[
<presence from='juliet@capulet.com/balcony' to='romeo@montague.net'> <presence from='juliet@capulet.com/balcony' to='romeo@montague.net'>
<status>anon!</status> <status>anon!</status>
@ -108,7 +108,7 @@
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
stamp='20020910T23:41:07'/> stamp='20020910T23:41:07'/>
</presence> </presence>
]]></example> ]]></example>
<example caption='Receiving Cached Messages from a Conference Room'><![CDATA[ <example caption='Receiving Cached Messages from a Conference Room'><![CDATA[
<message <message
from='coven@macbeth.shakespeare.lit/secondwitch' from='coven@macbeth.shakespeare.lit/secondwitch'
@ -124,7 +124,7 @@
from='coven@macbeth.shakespeare.lit' from='coven@macbeth.shakespeare.lit'
stamp='20020910T23:05:37'/> stamp='20020910T23:05:37'/>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='A Note on Time Formats' anchor='time'> <section1 topic='A Note on Time Formats' anchor='time'>
<p>&xep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:x:delay' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with XEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this document specifies that applications using 'jabber:x:delay' SHOULD use the old format, not the format defined in XEP-0082. The timezone is be understood as UTC.</p> <p>&xep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:x:delay' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with XEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this document specifies that applications using 'jabber:x:delay' SHOULD use the old format, not the format defined in XEP-0082. The timezone is be understood as UTC.</p>
@ -171,6 +171,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

10
xep-0092.xml
View File

@ -63,7 +63,7 @@
id='version_1'> id='version_1'>
<query xmlns='jabber:iq:version'/> <query xmlns='jabber:iq:version'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Receiving a Reply Regarding Software Version'><![CDATA[ <example caption='Receiving a Reply Regarding Software Version'><![CDATA[
<iq <iq
type='result' type='result'
@ -76,7 +76,7 @@
<os>Windows-XP 5.01.2600</os> <os>Windows-XP 5.01.2600</os>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p> <p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
</section1> </section1>
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
@ -87,7 +87,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Responding entity communicates protocol support'><![CDATA[ <example caption='Responding entity communicates protocol support'><![CDATA[
<iq from='conference.jabber.org' <iq from='conference.jabber.org'
to='stpeter@jabber.org/roundabout' to='stpeter@jabber.org/roundabout'
@ -98,7 +98,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>Revealing the application's underlying operating system may open the user or system to attacks directed against that operating system; therefore, an application MUST provide a way for a human user or administrator to disable sharing of information about the operating system.</p> <p>Revealing the application's underlying operating system may open the user or system to attacks directed against that operating system; therefore, an application MUST provide a way for a human user or administrator to disable sharing of information about the operating system.</p>
@ -137,6 +137,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

4
xep-0093.xml
View File

@ -80,7 +80,7 @@
</item> </item>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>
<p>There are no security features or concerns related to this proposal.</p> <p>There are no security features or concerns related to this proposal.</p>
@ -130,6 +130,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

6
xep-0094.xml
View File

@ -63,7 +63,7 @@
<iq id='agents1' type='get' to='shakespeare.lit'> <iq id='agents1' type='get' to='shakespeare.lit'>
<query xmlns='jabber:iq:agents'/> <query xmlns='jabber:iq:agents'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Reply Containing Agents List'><![CDATA[ <example caption='Reply Containing Agents List'><![CDATA[
<iq <iq
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
@ -84,7 +84,7 @@
</agent> </agent>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>
<p>There are no security features or concerns related to this proposal.</p> <p>There are no security features or concerns related to this proposal.</p>
@ -137,6 +137,6 @@
<xs:element name='search'/> <xs:element name='search'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

20
xep-0095.xml
View File

@ -113,7 +113,7 @@
id='info1'> id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this document. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:</p> <p>The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this document. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:</p>
<example caption='Receiver Disco Information Result'><![CDATA[ <example caption='Receiver Disco Information Result'><![CDATA[
<iq type='result' <iq type='result'
@ -127,7 +127,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Negotiating Profile and Stream' anchor='usecase-neg'> <section2 topic='Negotiating Profile and Stream' anchor='usecase-neg'>
<p>Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &xep0096;:</p> <p>Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &xep0096;:</p>
@ -153,7 +153,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>At this point the Receiver can view the profile and other information to decide if they wish to accept the Stream Initiation. If acceptable the Receiver MUST select one of the presented stream types to use.</p> <p>At this point the Receiver can view the profile and other information to decide if they wish to accept the Stream Initiation. If acceptable the Receiver MUST select one of the presented stream types to use.</p>
<example caption='Accept Stream Initiation'> <example caption='Accept Stream Initiation'>
<![CDATA[ <![CDATA[
@ -168,7 +168,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.</p> <p>If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.</p>
<example caption='Accept Stream Initiation with Profile'><![CDATA[ <example caption='Accept Stream Initiation with Profile'><![CDATA[
<iq type='result' to='sender@jabber.org/resource' id='offer1'> <iq type='result' to='sender@jabber.org/resource' id='offer1'>
@ -185,7 +185,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>If none of the stream types are acceptable, or if the profile is not understood, the Receiver MUST reply with a "bad request" error:</p> <p>If none of the stream types are acceptable, or if the profile is not understood, the Receiver MUST reply with a "bad request" error:</p>
<example caption='No Valid Streams'><![CDATA[ <example caption='No Valid Streams'><![CDATA[
<iq type='error' to='sender@jabber.org/resource' id='offer1'> <iq type='error' to='sender@jabber.org/resource' id='offer1'>
@ -194,7 +194,7 @@
<no-valid-streams xmlns='http://jabber.org/protocol/si'/> <no-valid-streams xmlns='http://jabber.org/protocol/si'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<example caption='Profile not understood'><![CDATA[ <example caption='Profile not understood'><![CDATA[
<iq type='error' to='sender@jabber.org/resource' id='offer1'> <iq type='error' to='sender@jabber.org/resource' id='offer1'>
<error code='400' type='cancel'> <error code='400' type='cancel'>
@ -202,7 +202,7 @@
<bad-profile xmlns='http://jabber.org/protocol/si'/> <bad-profile xmlns='http://jabber.org/protocol/si'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the Receiver rejects the request, they reply with a "forbidden" error:</p> <p>If the Receiver rejects the request, they reply with a "forbidden" error:</p>
<example caption='Rejecting Stream Initiation'><![CDATA[ <example caption='Rejecting Stream Initiation'><![CDATA[
<iq type='error' to='sender@jabber.org/resource' id='offer1'> <iq type='error' to='sender@jabber.org/resource' id='offer1'>
@ -211,7 +211,7 @@
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Offer Declined</text> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Offer Declined</text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Preparing the Transfer' anchor='usecase-transfer'> <section2 topic='Preparing the Transfer' anchor='usecase-transfer'>
<p>At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this document. This step now marks the end of SI's responsibilities.</p> <p>At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this document. This step now marks the end of SI's responsibilities.</p>
@ -317,7 +317,7 @@
<doc>The specification that defines the profile</doc> <doc>The specification that defines the profile</doc>
<desc>A natural-language description of the profile</desc> <desc>A natural-language description of the profile</desc>
</profile> </profile>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
</section2> </section2>
@ -371,6 +371,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

34
xep-0096.xml
View File

@ -197,7 +197,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Simple Profile Usage in Stream Initiation Result'> <example caption='Simple Profile Usage in Stream Initiation Result'>
<![CDATA[ <![CDATA[
@ -212,7 +212,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Complete Profile Usage in Stream Initiation Offer'> <example caption='Complete Profile Usage in Stream Initiation Offer'>
<![CDATA[ <![CDATA[
@ -238,7 +238,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption='Complete Profile Usage in Stream Initiation Result'> <example caption='Complete Profile Usage in Stream Initiation Result'>
<![CDATA[ <![CDATA[
@ -254,31 +254,31 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]> ]]>
</example> </example>
<p>This range should retrieve 256 bytes from the beginning of the file:</p> <p>This range should retrieve 256 bytes from the beginning of the file:</p>
<example> <example>
<![CDATA[ <![CDATA[
<range length='256'/> <range length='256'/>
]]> ]]>
</example> </example>
<p>This range should retrieve 256 bytes starting from the 128th byte in the file:</p> <p>This range should retrieve 256 bytes starting from the 128th byte in the file:</p>
<example> <example>
<![CDATA[ <![CDATA[
<range offset='128' length='256'/> <range offset='128' length='256'/>
]]> ]]>
</example> </example>
<p>This range should retrieve the remainder of the file starting at the 128th byte in the file:</p> <p>This range should retrieve the remainder of the file starting at the 128th byte in the file:</p>
<example> <example>
<![CDATA[ <![CDATA[
<range offset='128'/> <range offset='128'/>
]]> ]]>
</example> </example>
<p>This range is the same as having not sent the range request and the entire file is sent:</p> <p>This range is the same as having not sent the range request and the entire file is sent:</p>
<example> <example>
<![CDATA[ <![CDATA[
<range/> <range/>
]]> ]]>
</example> </example>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
@ -293,7 +293,7 @@
<doc>XEP-0096</doc> <doc>XEP-0096</doc>
<desc>A profile for file transfer between any two entities.</desc> <desc>A profile for file transfer between any two entities.</desc>
</profile> </profile>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='URI Query Types' anchor='registrar-querytypes'> <section2 topic='URI Query Types' anchor='registrar-querytypes'>
<p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p> <p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
@ -302,7 +302,7 @@
<p>To enable a second entity to send a file, the IRI/URI is of the following form:</p> <p>To enable a second entity to send a file, the IRI/URI is of the following form:</p>
<example caption='Sending a File: IRI/URI'><![CDATA[ <example caption='Sending a File: IRI/URI'><![CDATA[
xmpp:romeo@montague.net/orchard?sendfile xmpp:romeo@montague.net/orchard?sendfile
]]></example> ]]></example>
<p>The application SHOULD then present an interface enabling the user to provide information about the file to be sent (e.g., by "browsing" the file system of the user's computer in order to choose a file). As a result, the application SHOULD then send a &xep0137; message to the XMPP address encapsulated in the IRI/URI:</p> <p>The application SHOULD then present an interface enabling the user to provide information about the file to be sent (e.g., by "browsing" the file system of the user's computer in order to choose a file). As a result, the application SHOULD then send a &xep0137; message to the XMPP address encapsulated in the IRI/URI:</p>
<example caption='Sending a File: Resulting Stanza'><![CDATA[ <example caption='Sending a File: Resulting Stanza'><![CDATA[
<message from='juliet@capulet.com/balcony' to='romeo@montague.net'> <message from='juliet@capulet.com/balcony' to='romeo@montague.net'>
@ -316,7 +316,7 @@ xmpp:romeo@montague.net/orchard?sendfile
date='2005-11-29T11:21Z'/> date='2005-11-29T11:21Z'/>
</sipub> </sipub>
</message> </message>
]]></example> ]]></example>
<p>The following submission registers the "sendfile" querytype.</p> <p>The following submission registers the "sendfile" querytype.</p>
<code><![CDATA[ <code><![CDATA[
<querytype> <querytype>
@ -325,13 +325,13 @@ xmpp:romeo@montague.net/orchard?sendfile
<desc>enables initiation of an inbound file transfer to XMPP entity</desc> <desc>enables initiation of an inbound file transfer to XMPP entity</desc>
<doc>XEP-0096</doc> <doc>XEP-0096</doc>
</querytype> </querytype>
]]></code> ]]></code>
</section3> </section3>
<section3 topic='recvfile' anchor='registrar-querytypes-recvfile'> <section3 topic='recvfile' anchor='registrar-querytypes-recvfile'>
<p>To enable a second entity to receive a file, the IRI/URI is of the following form:</p> <p>To enable a second entity to receive a file, the IRI/URI is of the following form:</p>
<example caption='Receiving a File: IRI/URI'><![CDATA[ <example caption='Receiving a File: IRI/URI'><![CDATA[
xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=reply.txt;size=2048 xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=reply.txt;size=2048
]]></example> ]]></example>
<p>That IRI/URI is equivalent to the following XML stanza:</p> <p>That IRI/URI is equivalent to the following XML stanza:</p>
<example caption='Receiving a File: Equivalent Stanza'><![CDATA[ <example caption='Receiving a File: Equivalent Stanza'><![CDATA[
<message from='romeo@montague.net' to='juliet@capulet.com/balcony'> <message from='romeo@montague.net' to='juliet@capulet.com/balcony'>
@ -344,13 +344,13 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
size='2048'/> size='2048'/>
</sipub> </sipub>
</message> </message>
]]></example> ]]></example>
<p>In accordance with <cite>XEP-0137</cite>, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:</p> <p>In accordance with <cite>XEP-0137</cite>, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:</p>
<example caption='Receiving a File: Resulting Stanza'><![CDATA[ <example caption='Receiving a File: Resulting Stanza'><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'> <iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'>
<start xmlns='http://jabber.org/protocol/si-pub' id='pub234'/> <start xmlns='http://jabber.org/protocol/si-pub' id='pub234'/>
</iq> </iq>
]]></example> ]]></example>
<p>Note well that the request to begin the stream is sent to the full JID (user@host/resource) of the XMPP entity identified by the XMPP IRI/URI. Therefore, the IRI/URI SHOULD include a full JID. If it does not, the receiver MUST discover a full JID via presence or service discovery. If the receiver cannot discover a full JID for the sender (e.g., in the last resort through sending a presence subscription request to the sender and receiving presence from the sender's resources), then it SHOULD abort the file transfer exchange.</p> <p>Note well that the request to begin the stream is sent to the full JID (user@host/resource) of the XMPP entity identified by the XMPP IRI/URI. Therefore, the IRI/URI SHOULD include a full JID. If it does not, the receiver MUST discover a full JID via presence or service discovery. If the receiver cannot discover a full JID for the sender (e.g., in the last resort through sending a presence subscription request to the sender and receiving presence from the sender's resources), then it SHOULD abort the file transfer exchange.</p>
<p>The following submission registers the "recvfile" querytype.</p> <p>The following submission registers the "recvfile" querytype.</p>
<code><![CDATA[ <code><![CDATA[
@ -386,7 +386,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
</key> </key>
</keys> </keys>
</querytype> </querytype>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -438,6 +438,6 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0098.xml
View File

@ -107,7 +107,7 @@ SERVER:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1001"/> id="1001"/>
]]></example> ]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[ <example caption='Client Retrieves Private Data'><![CDATA[
CLIENT: CLIENT:
@ -129,7 +129,7 @@ SERVER:
</exodus> </exodus>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If a user attempts to get or set http://jabber.org/protocol/private-xml data that belongs to another user, the server must return an error to the sender. The error commonly used is 503 (Service Unavailable).</p> <p>If a user attempts to get or set http://jabber.org/protocol/private-xml data that belongs to another user, the server must return an error to the sender. The error commonly used is 503 (Service Unavailable).</p>
<example caption='User Attempts to Get or Set Data for Another User'><![CDATA[ <example caption='User Attempts to Get or Set Data for Another User'><![CDATA[
@ -155,7 +155,7 @@ SERVER:
</query> </query>
<error code="503">Service Unavailable</error> <error code="503">Service Unavailable</error>
</iq> </iq>
]]></example> ]]></example>
<p>If a user attempts to perform a get without providing a child element, the server should return a 406 (Not Acceptable) error:</p> <p>If a user attempts to perform a get without providing a child element, the server should return a 406 (Not Acceptable) error:</p>
<example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[ <example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[
CLIENT: CLIENT:
@ -168,7 +168,7 @@ SERVER:
<query xmlns="http://jabber.org/protocol/private-xml"/> <query xmlns="http://jabber.org/protocol/private-xml"/>
<error code="406">Not Acceptable</error> <error code="406">Not Acceptable</error>
</iq> </iq>
]]></example> ]]></example>
<p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set http://jabber.org/protocol/private-xml data in a reserved namespace, historically some server implementations have chosen to return an error (commonly 406 [Not Acceptable]) to the sender. Such behavior is not required in order to comply with this document, but may be encountered by clients when interacting with some current server implementations.</p> <p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set http://jabber.org/protocol/private-xml data in a reserved namespace, historically some server implementations have chosen to return an error (commonly 406 [Not Acceptable]) to the sender. Such behavior is not required in order to comply with this document, but may be encountered by clients when interacting with some current server implementations.</p>
<example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[ <example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[
CLIENT: CLIENT:
@ -189,7 +189,7 @@ SERVER (optional error):
</query> </query>
<error code="406">Not Acceptable</error> <error code="406">Not Acceptable</error>
</iq> </iq>
]]></example> ]]></example>
<p>The server always replies to a properly formatted get query with <p>The server always replies to a properly formatted get query with
a result response rather than some form of 'not found' error. a result response rather than some form of 'not found' error.
@ -213,7 +213,7 @@ SERVER (does not have data in "imaginary" namespace, returns empty element):
<data xmlns="imaginary"/> <data xmlns="imaginary"/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Finally, the client can delete data from the server using the delete query action.</p> <p>Finally, the client can delete data from the server using the delete query action.</p>
<example caption='User Deletes Data'><![CDATA[ <example caption='User Deletes Data'><![CDATA[
CLIENT: CLIENT:
@ -229,7 +229,7 @@ SERVER (server responds with success):
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1006"/> id="1006"/>
]]></example> ]]></example>
</section2> </section2>
@ -250,7 +250,7 @@ SERVER (server responds with success):
<code><![CDATA[ <code><![CDATA[
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<!ELEMENT query (#PCDATA)> <!ELEMENT query (#PCDATA)>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

20
xep-0099.xml
View File

@ -124,7 +124,7 @@ RECIPIENT:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1001"/> id="1001"/>
]]></example> ]]></example>
<p>With strict actions enabled, conflict data will cause the create action <p>With strict actions enabled, conflict data will cause the create action
to fail when existing data is on the recipient node. Here we show iq:private, and strict actions with existing data on the server.</p> to fail when existing data is on the recipient node. Here we show iq:private, and strict actions with existing data on the server.</p>
<example caption='Client Stores New Private Data but Conflicts'><![CDATA[ <example caption='Client Stores New Private Data but Conflicts'><![CDATA[
@ -149,7 +149,7 @@ RECIPIENT:
</exodus> </exodus>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -194,7 +194,7 @@ RECIPIENT:
</exodus> </exodus>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>With strict actions enabled, the absence of matching data will cause the read action <p>With strict actions enabled, the absence of matching data will cause the read action
to fail. Here we show iq:private, and strict actions with no matching data on the server.</p> to fail. Here we show iq:private, and strict actions with no matching data on the server.</p>
<example caption='Client Reads Private Data but Not Found (strict)'><![CDATA[ <example caption='Client Reads Private Data but Not Found (strict)'><![CDATA[
@ -215,7 +215,7 @@ RECIPIENT:
<data xmlns="imaginary"/> <data xmlns="imaginary"/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>With strict actions disabled, the absence of matching data will cause the read action <p>With strict actions disabled, the absence of matching data will cause the read action
to return an 'empty' result. Here we show iq:private, and strict actions disabled with no matching data to return an 'empty' result. Here we show iq:private, and strict actions disabled with no matching data
on the server.</p> on the server.</p>
@ -236,7 +236,7 @@ RECIPIENT:
<data xmlns="imaginary"/> <data xmlns="imaginary"/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -275,7 +275,7 @@ RECIPIENT:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1001"/> id="1001"/>
]]></example> ]]></example>
<p>With strict actions enabled, the absence of existing data will cause the update action <p>With strict actions enabled, the absence of existing data will cause the update action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p> to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Updates Private Data but None Found'><![CDATA[ <example caption='Client Updates Private Data but None Found'><![CDATA[
@ -300,7 +300,7 @@ RECIPIENT:
</exodus> </exodus>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -337,7 +337,7 @@ RECIPIENT:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1001"/> id="1001"/>
]]></example> ]]></example>
<p>With strict actions enabled, the absence of existing data will cause the delete action <p>With strict actions enabled, the absence of existing data will cause the delete action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p> to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Deletes Private Data but None Found (strict)'><![CDATA[ <example caption='Client Deletes Private Data but None Found (strict)'><![CDATA[
@ -358,7 +358,7 @@ RECIPIENT:
<data xmlns="imaginary"/> <data xmlns="imaginary"/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>With strict actions disabled, the absence of existing data will not cause the delete action <p>With strict actions disabled, the absence of existing data will not cause the delete action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p> to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Deletes Private Data but None Found (not strict)'><![CDATA[ <example caption='Client Deletes Private Data but None Found (not strict)'><![CDATA[
@ -375,7 +375,7 @@ RECIPIENT:
from="hamlet@shakespeare.lit/denmark" from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark"
id="1003"/> id="1003"/>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Defining an Action Protocol'> <section1 topic='Defining an Action Protocol'>

112
xep-0100.xml
View File

@ -158,7 +158,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="User Queries Gateway's Parent Regarding Agent Information"><![CDATA[ <example caption="User Queries Gateway's Parent Regarding Agent Information"><![CDATA[
<iq type='get' <iq type='get'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
@ -166,7 +166,7 @@
id='agent1'> id='agent1'>
<query xmlns='jabber:iq:agents'/> <query xmlns='jabber:iq:agents'/>
</iq> </iq>
]]></example> ]]></example>
<p>Note: Although many existing gateway implementations support only the older Agent Information protocol, it is RECOMMENDED that gateways support the Service Discovery protocol, since the former protocol is deprecated in favor of the latter. Until existing gateways are upgraded, clients SHOULD support both.</p> <p>Note: Although many existing gateway implementations support only the older Agent Information protocol, it is RECOMMENDED that gateways support the Service Discovery protocol, since the former protocol is deprecated in favor of the latter. Until existing gateways are upgraded, clients SHOULD support both.</p>
</li> </li>
<li> <li>
@ -186,7 +186,7 @@
<feature var='jabber:iq:version'/> <feature var='jabber:iq:version'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="Gateway's Parent Returns Agent Information"><![CDATA[ <example caption="Gateway's Parent Returns Agent Information"><![CDATA[
<iq type='result' <iq type='result'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
@ -201,7 +201,7 @@
</agent> </agent>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: Given the foregoing, a client can determine the identity of the gateway, specifically (1) that it is a gateway and (2) to which legacy service it provides a gateway.</p> <p>Note: Given the foregoing, a client can determine the identity of the gateway, specifically (1) that it is a gateway and (2) to which legacy service it provides a gateway.</p>
</li> </li>
<li> <li>
@ -213,7 +213,7 @@
id='reg1'> id='reg1'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway returns IQ-result to Jabber User, specifying information that is required in order to register.</p> <p>Gateway returns IQ-result to Jabber User, specifying information that is required in order to register.</p>
@ -230,7 +230,7 @@
<password/> <password/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing information required to register.</p> <p>Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing information required to register.</p>
@ -244,7 +244,7 @@
<password>ILoveJuliet</password> <password>ILoveJuliet</password>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The XML character data of the &lt;username/&gt; element SHOULD be the Jabber User's LegacyUserAddress as described under <link url='#addressing'>Addressing</link>, such as an AOL screen name, ICQ number, Windows Live Messenger (formerly MSN Messenger) address, or Yahoo! ID.</p> <p>Note: The XML character data of the &lt;username/&gt; element SHOULD be the Jabber User's LegacyUserAddress as described under <link url='#addressing'>Addressing</link>, such as an AOL screen name, ICQ number, Windows Live Messenger (formerly MSN Messenger) address, or Yahoo! ID.</p>
</li> </li>
<li> <li>
@ -254,7 +254,7 @@
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
id='reg2'/> id='reg2'/>
]]></example> ]]></example>
</li> </li>
<li><p>If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.</p></li> <li><p>If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.</p></li>
<li> <li>
@ -267,12 +267,12 @@
<item jid='aim.shakespeare.lit' name='AIM Gateway'/> <item jid='aim.shakespeare.lit' name='AIM Gateway'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="Server Response"><![CDATA[ <example caption="Server Response"><![CDATA[
<iq type='result' <iq type='result'
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
id='roster1'/> id='roster1'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends subscription request to Jabber User (i.e., by sending a presence stanza of type "subscribe" to Jabber User's bare JID).</p> <p>Gateway sends subscription request to Jabber User (i.e., by sending a presence stanza of type "subscribe" to Jabber User's bare JID).</p>
@ -280,7 +280,7 @@
<presence type='subscribe' <presence type='subscribe'
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).</p> <p>Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).</p>
@ -288,7 +288,7 @@
<presence type='subscribed' <presence type='subscribed'
from='romeo@montague.lit' from='romeo@montague.lit'
to='aim.shakespeare.lit'/> to='aim.shakespeare.lit'/>
]]></example> ]]></example>
<p>Note: As specified in <cite>RFC 6121</cite>, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).</p> <p>Note: As specified in <cite>RFC 6121</cite>, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).</p>
</li> </li>
<li> <li>
@ -297,7 +297,7 @@
<presence type='subscribe' <presence type='subscribe'
from='romeo@montague.lit' from='romeo@montague.lit'
to='aim.shakespeare.lit'/> to='aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends approves subscription request (i.e., by sending a presence stanza of type "subscribed" to Jabber User's bare JID).</p> <p>Gateway sends approves subscription request (i.e., by sending a presence stanza of type "subscribed" to Jabber User's bare JID).</p>
@ -305,7 +305,7 @@
<presence type='subscribed' <presence type='subscribed'
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Execute "Log In" use case.</p></li> <li><p>Execute "Log In" use case.</p></li>
<li><p>Gateway sends any buffered messages to Jabber User.</p></li> <li><p>Gateway sends any buffered messages to Jabber User.</p></li>
@ -332,7 +332,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends unsuccessfully.</p></li> <li><p>Use Case Ends unsuccessfully.</p></li>
</ol> </ol>
@ -353,7 +353,7 @@
id='edit1'> id='edit1'>
<query xmlns='jabber:iq:register'/> <query xmlns='jabber:iq:register'/>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway returns IQ-result to Jabber User, specifying registration information on record and including empty &lt;registered/&gt; element to signify that user is already registered. <note>The fact that the Gateway can determine the Jabber User's legacy username based on the JID of the 'from' address indicates that the client proxy model assumes one registration per Jabber User.</note></p> <p>Gateway returns IQ-result to Jabber User, specifying registration information on record and including empty &lt;registered/&gt; element to signify that user is already registered. <note>The fact that the Gateway can determine the Jabber User's legacy username based on the JID of the 'from' address indicates that the client proxy model assumes one registration per Jabber User.</note></p>
@ -368,7 +368,7 @@
<password>ILoveJuliet</password> <password>ILoveJuliet</password>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").</p> <p>Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").</p>
@ -382,7 +382,7 @@
<password>B4lc0ny</password> <password>B4lc0ny</password>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway verifies that, if changed, information provided by Jabber User is still valid (using whatever means appropriate for the Legacy Service) and informs Jabber User of success [A1].</p> <p>Gateway verifies that, if changed, information provided by Jabber User is still valid (using whatever means appropriate for the Legacy Service) and informs Jabber User of success [A1].</p>
@ -391,7 +391,7 @@
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
id='edit2'/> id='edit2'/>
]]></example> ]]></example>
</li> </li>
</ol> </ol>
</section3> </section3>
@ -415,7 +415,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends unsuccessfully.</p></li> <li><p>Use Case Ends unsuccessfully.</p></li>
</ol> </ol>
@ -438,7 +438,7 @@
<remove/> <remove/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway sends unavailable presence from Jabber User to Legacy Users and logs Jabber User out of Legacy Service.</p></li> <li><p>Gateway sends unavailable presence from Jabber User to Legacy Users and logs Jabber User out of Legacy Service.</p></li>
<li><p>Gateway deletes Jabber User's information.</p></li> <li><p>Gateway deletes Jabber User's information.</p></li>
@ -449,7 +449,7 @@
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'
id='unreg1'/> id='unreg1'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway cancels subscriptions.</p> <p>Gateway cancels subscriptions.</p>
@ -461,7 +461,7 @@
<presence type='unsubscribed' <presence type='unsubscribed'
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends unavailable presence to Jabber User.</p> <p>Gateway sends unavailable presence to Jabber User.</p>
@ -469,7 +469,7 @@
<presence type='unavailable' <presence type='unavailable'
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy Contacts associated with the gateway.</p></li> <li><p>Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy Contacts associated with the gateway.</p></li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
@ -487,14 +487,14 @@
<p>Jabber User sends available presence broadcast to Server or sends directed presence to Gateway or a Legacy User.</p> <p>Jabber User sends available presence broadcast to Server or sends directed presence to Gateway or a Legacy User.</p>
<example caption="Jabber User Sends Available Presence"><![CDATA[ <example caption="Jabber User Sends Available Presence"><![CDATA[
<presence/> <presence/>
]]></example> ]]></example>
<example caption="Jabber User's Server Broadcasts Available Presence"><![CDATA[ <example caption="Jabber User's Server Broadcasts Available Presence"><![CDATA[
<presence from='romeo@montague.lit/orchard' <presence from='romeo@montague.lit/orchard'
to='juliet@aim.shakespeare.lit'/> to='juliet@aim.shakespeare.lit'/>
<presence from='romeo@montague.lit/orchard' <presence from='romeo@montague.lit/orchard'
to='aim.shakespeare.lit'/> to='aim.shakespeare.lit'/>
... ...
]]></example> ]]></example>
</li> </li>
<li><p>Upon receiving the first presence notification stanza from Jabber User to Gateway or Legacy User, Gateway logs Jabber User into Legacy Service [A1].</p></li> <li><p>Upon receiving the first presence notification stanza from Jabber User to Gateway or Legacy User, Gateway logs Jabber User into Legacy Service [A1].</p></li>
<li> <li>
@ -502,7 +502,7 @@
<example caption="Gateway Sends Presence to Jabber User"><![CDATA[ <example caption="Gateway Sends Presence to Jabber User"><![CDATA[
<presence from='aim.shakespeare.lit' <presence from='aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Optionally, Gateway handles Legacy Service contact list; see the <link url="#rosters">Contact Lists</link> section of this document.</p></li> <li><p>Optionally, Gateway handles Legacy Service contact list; see the <link url="#rosters">Contact Lists</link> section of this document.</p></li>
<li> <li>
@ -512,7 +512,7 @@
to='romeo@montague.lit'> to='romeo@montague.lit'>
<show>away</show> <show>away</show>
</presence> </presence>
]]></example> ]]></example>
<p>Note: If the Legacy Service to which the Gateway connects does not support the concept of "resources", the 'from' address of presence notification stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p> <p>Note: If the Legacy Service to which the Gateway connects does not support the concept of "resources", the 'from' address of presence notification stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
</li> </li>
<li> <li>
@ -523,7 +523,7 @@
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
</presence> </presence>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
</ol> </ol>
@ -543,7 +543,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends unsuccessfully.</p></li> <li><p>Use Case Ends unsuccessfully.</p></li>
</ol> </ol>
@ -559,12 +559,12 @@
<p>Jabber User sends unavailable presence broadcast to Server or sends directed presence stanza of type "unavailable" to Gateway or (if Gateway does not support directed presence) Legacy User.</p> <p>Jabber User sends unavailable presence broadcast to Server or sends directed presence stanza of type "unavailable" to Gateway or (if Gateway does not support directed presence) Legacy User.</p>
<example caption="Jabber User Sends Unavailable Presence"><![CDATA[ <example caption="Jabber User Sends Unavailable Presence"><![CDATA[
<presence type='unavailable'/> <presence type='unavailable'/>
]]></example> ]]></example>
<example caption="Jabber User's Server Broadcasts Unavailable Presence"><![CDATA[ <example caption="Jabber User's Server Broadcasts Unavailable Presence"><![CDATA[
<presence type='unavailable' <presence type='unavailable'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
to='aim.shakespeare.lit'/> to='aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway transforms unavailable presence stanzas received from the Jabber User's server and routes them to all of the Jabber User's contacts on Legacy Service.</p></li> <li><p>Gateway transforms unavailable presence stanzas received from the Jabber User's server and routes them to all of the Jabber User's contacts on Legacy Service.</p></li>
<li><p>Gateway logs Jabber User out of Legacy Service [A1].</p></li> <li><p>Gateway logs Jabber User out of Legacy Service [A1].</p></li>
@ -574,7 +574,7 @@
<presence type='unavailable' <presence type='unavailable'
from='aim.shakespeare.lit' from='aim.shakespeare.lit'
to='romeo@montague.lit/orchard'/> to='romeo@montague.lit/orchard'/>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
</ol> </ol>
@ -589,7 +589,7 @@
<presence type='unavailable' <presence type='unavailable'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
to='juliet@aim.shakespeare.lit'/> to='juliet@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
</ol> </ol>
@ -607,7 +607,7 @@
<presence type='subscribe' <presence type='subscribe'
from='romeo@montague.lit' from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
<p>Note: As specified in <cite>RFC 6121</cite>, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.</p> <p>Note: As specified in <cite>RFC 6121</cite>, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.</p>
</li> </li>
<li><p>Gateway transforms subscription request and routes it to Legacy User.</p></li> <li><p>Gateway transforms subscription request and routes it to Legacy User.</p></li>
@ -617,14 +617,14 @@
<presence type='subscribed' <presence type='subscribed'
from='CapuletNurse@aim.shakespeare.lit' from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends available presence stanza to Jabber User on behalf of Legacy User.</p> <p>Gateway sends available presence stanza to Jabber User on behalf of Legacy User.</p>
<example caption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[ <example caption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[
<presence from='CapuletNurse@aim.shakespeare.lit' <presence from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit/orchard'/> to='romeo@montague.lit/orchard'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User.</p> <p>Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User.</p>
@ -632,7 +632,7 @@
<presence type='subscribe' <presence type='subscribe'
from='CapuletNurse@aim.shakespeare.lit' from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Jabber User sends presence stanza of type "subscribed" to Legacy User.</p> <p>Jabber User sends presence stanza of type "subscribed" to Legacy User.</p>
@ -640,7 +640,7 @@
<presence type='subscribed' <presence type='subscribed'
from='romeo@montague.lit' from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
</ol> </ol>
@ -656,7 +656,7 @@
<presence type='unsubscribed' <presence type='unsubscribed'
from='juliet@aim.shakespeare.lit' from='juliet@aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends unsuccessfully.</p></li> <li><p>Use Case Ends unsuccessfully.</p></li>
</ol> </ol>
@ -679,7 +679,7 @@
subscription='remove'/> subscription='remove'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Server sends normal "roster push" to Jabber User (see <cite>RFC 6121</cite>) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.</p> <p>Server sends normal "roster push" to Jabber User (see <cite>RFC 6121</cite>) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.</p>
@ -695,7 +695,7 @@
<presence type='unavailable' <presence type='unavailable'
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway cleans up subscription state, informs Legacy User that Jabber User is unavailable, and MUST NOT send future changes in Jabber User's presence to Legacy User.</p></li> <li><p>Gateway cleans up subscription state, informs Legacy User that Jabber User is unavailable, and MUST NOT send future changes in Jabber User's presence to Legacy User.</p></li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
@ -717,7 +717,7 @@
type='chat'> type='chat'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
</message> </message>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway transforms message to legacy protocol and sends to Legacy User [A1].</p></li> <li><p>Gateway transforms message to legacy protocol and sends to Legacy User [A1].</p></li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
@ -752,7 +752,7 @@
<presence type='subscribe' <presence type='subscribe'
from='CapuletNurse@aim.shakespeare.lit' from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].</p> <p>Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].</p>
@ -760,7 +760,7 @@
<presence type='subscribed' <presence type='subscribed'
from='romeo@montague.lit' from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway sends Jabber User's presence information to Legacy User.</p></li> <li><p>Gateway sends Jabber User's presence information to Legacy User.</p></li>
<li> <li>
@ -769,7 +769,7 @@
<presence type='subscribe' <presence type='subscribe'
from='romeo@montague.lit' from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User.</p> <p>Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User.</p>
@ -777,14 +777,14 @@
<presence type='subscribed' <presence type='subscribed'
from='CapuletNurse@aim.shakespeare.lit' from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit'/> to='romeo@montague.lit'/>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>Gateway sends Legacy User's presence information to Jabber User.</p> <p>Gateway sends Legacy User's presence information to Jabber User.</p>
<example caption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[ <example caption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[
<presence from='CapuletNurse@aim.shakespeare.lit' <presence from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit/orchard'/> to='romeo@montague.lit/orchard'/>
]]></example> ]]></example>
</li> </li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
</ol> </ol>
@ -799,7 +799,7 @@
<presence type='unsubscribed' <presence type='unsubscribed'
from='romeo@montague.lit' from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/> to='CapuletNurse@aim.shakespeare.lit'/>
]]></example> ]]></example>
</li> </li>
<li><p>Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.</p></li> <li><p>Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.</p></li>
<li><p>Use Case Ends unsuccessfully.</p></li> <li><p>Use Case Ends unsuccessfully.</p></li>
@ -827,7 +827,7 @@
<presence type='unavailable' <presence type='unavailable'
from='CapuletNurse@aim.shakespeare.lit' from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.lit/orchard'/> to='romeo@montague.lit/orchard'/>
]]></example> ]]></example>
</li> </li>
<li><p>Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see <cite>RFC 6121</cite>).</p></li> <li><p>Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see <cite>RFC 6121</cite>).</p></li>
<li><p>Use Case Ends.</p></li> <li><p>Use Case Ends.</p></li>
@ -849,7 +849,7 @@
to='romeo@montague.lit'> to='romeo@montague.lit'>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
]]></example> ]]></example>
<p>Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc6120;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p> <p>Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc6120;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
</li> </li>
<li><p>Jabber User's Server delivers message or (optionally) stores it for later retrieval.</p></li> <li><p>Jabber User's Server delivers message or (optionally) stores it for later retrieval.</p></li>
@ -886,7 +886,7 @@
<iq type='get' to='aim.jabber.org' from='stpeter@jabber.org/roundabout' id='gate1'> <iq type='get' to='aim.jabber.org' from='stpeter@jabber.org/roundabout' id='gate1'>
<query xmlns='jabber:iq:gateway'/> <query xmlns='jabber:iq:gateway'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Gateway Returns Prompt'><![CDATA[ <example caption='Gateway Returns Prompt'><![CDATA[
<iq type='result' from='aim.jabber.org' to='stpeter@jabber.org/roundabout' id='gate1'> <iq type='result' from='aim.jabber.org' to='stpeter@jabber.org/roundabout' id='gate1'>
<query xmlns='jabber:iq:gateway'> <query xmlns='jabber:iq:gateway'>
@ -897,7 +897,7 @@
<prompt>Contact ID</prompt> <prompt>Contact ID</prompt>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The following table is intended to assist implementors with mapping of gateway identities to English-language prompt names and text.</p> <p>The following table is intended to assist implementors with mapping of gateway identities to English-language prompt names and text.</p>
<table caption='Prompt Item Mapping (English)'> <table caption='Prompt Item Mapping (English)'>
<tr> <tr>
@ -939,14 +939,14 @@
<prompt>Foo Bar</prompt> <prompt>Foo Bar</prompt>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Gateway Returns JID'><![CDATA[ <example caption='Gateway Returns JID'><![CDATA[
<iq type='result' from='aim.jabber.org' to='stpeter@jabber.org/roundabout' id='gate1'> <iq type='result' from='aim.jabber.org' to='stpeter@jabber.org/roundabout' id='gate1'>
<query xmlns='jabber:iq:gateway'> <query xmlns='jabber:iq:gateway'>
<jid>FooBar@aim.jabber.org</jid> <jid>FooBar@aim.jabber.org</jid>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Contact Lists' anchor='rosters'> <section1 topic='Contact Lists' anchor='rosters'>
@ -1021,6 +1021,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

22
xep-0103.xml
View File

@ -75,7 +75,7 @@
xmlns='http://jabber.org/protocol/url-data' xmlns='http://jabber.org/protocol/url-data'
target='http://festhall.outer-planes.net/d20M/announce/latest/'/> target='http://festhall.outer-planes.net/d20M/announce/latest/'/>
</message> </message>
]]></example> ]]></example>
<p>If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &xep0104;:</p> <p>If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &xep0104;:</p>
<example caption='Exchanging a HTTP URL with Headers'><![CDATA[ <example caption='Exchanging a HTTP URL with Headers'><![CDATA[
<message from='d20M@festhall.outer-planes.net' <message from='d20M@festhall.outer-planes.net'
@ -88,7 +88,7 @@
<http:header name='Cookie'>jsessionid=1324123wdwfq341w1243asdf'</http:header> <http:header name='Cookie'>jsessionid=1324123wdwfq341w1243asdf'</http:header>
</url-data> </url-data>
</message> </message>
]]></example> ]]></example>
<p>The above example illustrates supplying a HTTP URL with a cookie header. Additional information could be provided, such as HTTP authentication requirements or even POST data.</p> <p>The above example illustrates supplying a HTTP URL with a cookie header. Additional information could be provided, such as HTTP authentication requirements or even POST data.</p>
<p>To support the use of bulk publishing methods such as &xep0060; or messages of type "headline", the &lt;desc/&gt; element is used to provide a textual description:</p> <p>To support the use of bulk publishing methods such as &xep0060; or messages of type "headline", the &lt;desc/&gt; element is used to provide a textual description:</p>
<example caption='&MESSAGE; Headines'><![CDATA[ <example caption='&MESSAGE; Headines'><![CDATA[
@ -119,7 +119,7 @@
<desc>Greyhawk in 3rd Edition</desc> <desc>Greyhawk in 3rd Edition</desc>
</url-data> </url-data>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='SI Usage'> <section2 topic='SI Usage'>
<p>To use "url-data" in conjunction with SI, the "sid" attribute of &lt;url-data/&gt; is used. This attribute MUST be equal to the SI session id.</p> <p>To use "url-data" in conjunction with SI, the "sid" attribute of &lt;url-data/&gt; is used. This attribute MUST be equal to the SI session id.</p>
@ -156,7 +156,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>The receiver then accepts the request, specifying "url-data" as the stream method:</p> <p>The receiver then accepts the request, specifying "url-data" as the stream method:</p>
<example caption=''><![CDATA[ <example caption=''><![CDATA[
<iq type='result' to='sender@jabber.org/resource' id='offer1'> <iq type='result' to='sender@jabber.org/resource' id='offer1'>
@ -170,7 +170,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>The sender then sends an &IQ; with type "set" to the receiver, providing the &lt;url-data/&gt; element with the URL in the "target" attribute:</p> <p>The sender then sends an &IQ; with type "set" to the receiver, providing the &lt;url-data/&gt; element with the URL in the "target" attribute:</p>
<example caption='Providing &lt;url-data/&gt;'><![CDATA[ <example caption='Providing &lt;url-data/&gt;'><![CDATA[
<iq type='set' from='sender@jabber.org/resource' to='receiver@jabber.org/resource' id='offer2'> <iq type='set' from='sender@jabber.org/resource' to='receiver@jabber.org/resource' id='offer2'>
@ -178,7 +178,7 @@
sid='a0' sid='a0'
target='http://pass.jabber.org:8519/test.txt'/> target='http://pass.jabber.org:8519/test.txt'/>
</iq> </iq>
]]></example> ]]></example>
<p>The receiver attempts to retrieve the data from the given URL. The receiver MUST NOT respond to the &IQ; until the data is completely retrieved, or an error occurs. If the retrieval is successful, the receiver responds with an "iq-result":</p> <p>The receiver attempts to retrieve the data from the given URL. The receiver MUST NOT respond to the &IQ; until the data is completely retrieved, or an error occurs. If the retrieval is successful, the receiver responds with an "iq-result":</p>
<example caption='Receiver responds successfully'><![CDATA[ <example caption='Receiver responds successfully'><![CDATA[
<iq type='result' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'> <iq type='result' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'>
@ -186,7 +186,7 @@
sid='a0' sid='a0'
target='http://pass.jabber.org:8519/test.txt'/> target='http://pass.jabber.org:8519/test.txt'/>
</iq> </iq>
]]></example> ]]></example>
<p>Including the &lt;url-data/&gt; element in the result is NOT REQUIRED.</p> <p>Including the &lt;url-data/&gt; element in the result is NOT REQUIRED.</p>
<p>If the receiver does not understand or support the URL, it responds with an "iq-error" with the &lt;malformed-url/&gt; condition:</p> <p>If the receiver does not understand or support the URL, it responds with an "iq-error" with the &lt;malformed-url/&gt; condition:</p>
<example caption='Receiver does not understand/support URL'><![CDATA[ <example caption='Receiver does not understand/support URL'><![CDATA[
@ -199,7 +199,7 @@
<malformed-url xmlns='http://jabber.org/protocol/url-data'/> <malformed-url xmlns='http://jabber.org/protocol/url-data'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the receiver fails to retrieve data from the URL, it responds with an "iq-error" with the &lt;transfer-failed/&gt; condition:</p> <p>If the receiver fails to retrieve data from the URL, it responds with an "iq-error" with the &lt;transfer-failed/&gt; condition:</p>
<example caption='Receiver does not understand/support URL'><![CDATA[ <example caption='Receiver does not understand/support URL'><![CDATA[
<iq type='error' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'> <iq type='error' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'>
@ -211,7 +211,7 @@
<transfer-failed xmlns='http://jabber.org/protocol/url-data'/> <transfer-failed xmlns='http://jabber.org/protocol/url-data'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the receiver refuses to accept the URL, it responds with an "iq-error" with the &lt;transfer-refused/&gt; condition:</p> <p>If the receiver refuses to accept the URL, it responds with an "iq-error" with the &lt;transfer-refused/&gt; condition:</p>
<example caption='Receiver does not understand/support URL'><![CDATA[ <example caption='Receiver does not understand/support URL'><![CDATA[
<iq type='error' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'> <iq type='error' from='receiver@jabber.org/resource' to='sender@jabber.org/resource' id='offer2'>
@ -223,7 +223,7 @@
<transfer-refused xmlns='http://jabber.org/protocol/url-data'/> <transfer-refused xmlns='http://jabber.org/protocol/url-data'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes'> <section1 topic='Implementation Notes'>
@ -320,7 +320,7 @@
<xs:element name='transfer-refused'/> <xs:element name='transfer-refused'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>

12
xep-0104.xml
View File

@ -73,7 +73,7 @@
<http:auth scheme='basic'/> <http:auth scheme='basic'/>
</url-data> </url-data>
</message> </message>
]]></example> ]]></example>
<p>To provide additional parameters (such as a realm and username/password), the &lt;auth-param/&gt; element is used:</p> <p>To provide additional parameters (such as a realm and username/password), the &lt;auth-param/&gt; element is used:</p>
<code><![CDATA[ <code><![CDATA[
<message to='client@domain.com'> <message to='client@domain.com'>
@ -87,7 +87,7 @@
</http:auth> </http:auth>
</url-data> </url-data>
</message> </message>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Providing Cookies'> <section2 topic='Providing Cookies'>
<p>Cookie information is provided by the &lt;cookie/&gt; element. This element can provide all of the information of the "Set-Cookie" response header<note>"Set-Cookie" is a message header for the HTTP response, and the &lt;header/&gt; element represents only message headers for HTTP requests. Therefore, cookies are handled differently.</note>. The simplest usage is:</p> <p>Cookie information is provided by the &lt;cookie/&gt; element. This element can provide all of the information of the "Set-Cookie" response header<note>"Set-Cookie" is a message header for the HTTP response, and the &lt;header/&gt; element represents only message headers for HTTP requests. Therefore, cookies are handled differently.</note>. The simplest usage is:</p>
@ -99,7 +99,7 @@
<http:cookie name='jsessionid' value='1243asd234190sa32ds'/> <http:cookie name='jsessionid' value='1243asd234190sa32ds'/>
</url-data> </url-data>
</message> </message>
]]></code> ]]></code>
<p>The above cookie is considered "transient", and will terminate when the HTTP session ends. Additional information about the cookie can be provided:</p> <p>The above cookie is considered "transient", and will terminate when the HTTP session ends. Additional information about the cookie can be provided:</p>
<code><![CDATA[ <code><![CDATA[
<message to='client@domain.com'> <message to='client@domain.com'>
@ -116,7 +116,7 @@
value='1243asd234190sa32ds'/> value='1243asd234190sa32ds'/>
</url-data> </url-data>
</message> </message>
]]></code> ]]></code>
<p>As demonstrated, the &lt;cookie/&gt; provides all the attributes provided by the "Set-Cookie" header. The only attributes required are "name" and "value".</p> <p>As demonstrated, the &lt;cookie/&gt; provides all the attributes provided by the "Set-Cookie" header. The only attributes required are "name" and "value".</p>
</section2> </section2>
<section2 topic='Providing Headers'> <section2 topic='Providing Headers'>
@ -129,7 +129,7 @@
<http:header name='Custom-Data' value='some custom data'/> <http:header name='Custom-Data' value='some custom data'/>
</url-data> </url-data>
</message> </message>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes'> <section1 topic='Implementation Notes'>
@ -222,7 +222,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>

10
xep-0105.xml
View File

@ -116,7 +116,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<example caption='Simple Profile Usage in Stream Initiation Result'><![CDATA[ <example caption='Simple Profile Usage in Stream Initiation Result'><![CDATA[
<iq type='result' to='sender@jabber.org/resource' id='offer1'> <iq type='result' to='sender@jabber.org/resource' id='offer1'>
<si xmlns='http://jabber.org/protocol/si'> <si xmlns='http://jabber.org/protocol/si'>
@ -129,7 +129,7 @@
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<example caption='Subsequent File Transfer Offer'><![CDATA[ <example caption='Subsequent File Transfer Offer'><![CDATA[
<iq type='set' id='offer2' to='receiver@jabber.org/resource'> <iq type='set' id='offer2' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si' <si xmlns='http://jabber.org/protocol/si'
@ -141,12 +141,12 @@
size='500'/> size='500'/>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<example caption='Subsequent File Transfer Result'><![CDATA[ <example caption='Subsequent File Transfer Result'><![CDATA[
<iq type='result' to='sender@jabber.org/resource' id='offer2'> <iq type='result' to='sender@jabber.org/resource' id='offer2'>
<si xmlns='http://jabber.org/protocol/si'/> <si xmlns='http://jabber.org/protocol/si'/>
</iq> </iq>
]]></example> ]]></example>
<p>Above is repeated for ft2, ft3, etc...</p> <p>Above is repeated for ft2, ft3, etc...</p>
</section1> </section1>
<section1 topic='IANA Considerations'> <section1 topic='IANA Considerations'>
@ -194,6 +194,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0107.xml
View File

@ -91,7 +91,7 @@
<happy/> <happy/>
<text>Yay, the mood spec has been approved!</text> <text>Yay, the mood spec has been approved!</text>
</mood> </mood>
]]></code> ]]></code>
<p>In addition, an application MAY provide a more specific mood value as a properly-namespaced child of the defined element, which extension MUST be ignored if the receiving application does not understand the extended namespace. Here is an example:</p> <p>In addition, an application MAY provide a more specific mood value as a properly-namespaced child of the defined element, which extension MUST be ignored if the receiving application does not understand the extended namespace. Here is an example:</p>
<code><![CDATA[ <code><![CDATA[
<mood xmlns='http://jabber.org/protocol/mood'> <mood xmlns='http://jabber.org/protocol/mood'>
@ -100,7 +100,7 @@
</happy> </happy>
<text>Yay, the mood spec has been approved!</text> <text>Yay, the mood spec has been approved!</text>
</mood> </mood>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Pubsub Transport' anchor='proto-pubsub'> <section2 topic='Pubsub Transport' anchor='proto-pubsub'>
<p>Mood information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p> <p>Mood information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
@ -119,7 +119,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The mood is then delivered to all subscribers:</p> <p>The mood is then delivered to all subscribers:</p>
<example caption='Mood is Delivered to All Subscribers'><![CDATA[ <example caption='Mood is Delivered to All Subscribers'><![CDATA[
<message <message
@ -136,7 +136,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>In order to indicate that the user is no longer publishing moods, the user's client shall send an empty &lt;mood/&gt; element, which can be considered a "stop command" for user moods:</p> <p>In order to indicate that the user is no longer publishing moods, the user's client shall send an empty &lt;mood/&gt; element, which can be considered a "stop command" for user moods:</p>
<example caption='User Disables Publishing'><![CDATA[ <example caption='User Disables Publishing'><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
@ -150,7 +150,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Empty Mood Information is Delivered to All Subscribers'><![CDATA[ <example caption='Empty Mood Information is Delivered to All Subscribers'><![CDATA[
<message <message
from='juliet@capulet.lit' from='juliet@capulet.lit'
@ -163,7 +163,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Including a Mood in a IM Message' anchor='proto-message'> <section2 topic='Including a Mood in a IM Message' anchor='proto-message'>
<p>A user MAY provide a mood extension in a specific IM message in order to lend a defined emotional tone to text of that particular message. (This does not override the user's more general mood and is not intended to replace PEP as a more general transport method for user moods.)</p> <p>A user MAY provide a mood extension in a specific IM message in order to lend a defined emotional tone to text of that particular message. (This does not override the user's more general mood and is not intended to replace PEP as a more general transport method for user moods.)</p>
@ -176,7 +176,7 @@
<sad/> <sad/>
</mood> </mood>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Mood Values' anchor='moods'> <section1 topic='Mood Values' anchor='moods'>
@ -407,6 +407,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0108.xml
View File

@ -87,7 +87,7 @@
</relaxing> </relaxing>
<text xml:lang='en'>My nurse&apos;s birthday!</text> <text xml:lang='en'>My nurse&apos;s birthday!</text>
</activity> </activity>
]]></code> ]]></code>
<p>Instead of (but not in addition to) one of the specific activity elements defined herein, an application MAY include a properly-namespaced child element for the specific activity. Here is an example:</p> <p>Instead of (but not in addition to) one of the specific activity elements defined herein, an application MAY include a properly-namespaced child element for the specific activity. Here is an example:</p>
<code><![CDATA[ <code><![CDATA[
<activity xmlns='http://jabber.org/protocol/activity'> <activity xmlns='http://jabber.org/protocol/activity'>
@ -95,7 +95,7 @@
<tanning xmlns='http://www.ilovetanning.info'/> <tanning xmlns='http://www.ilovetanning.info'/>
</relaxing> </relaxing>
</activity> </activity>
]]></code> ]]></code>
<p>Finally, one of the specific activity elements defined herein MAY itself contain a properly-namespaced child element that provides more detailed information about the specific activity. Here is an example:</p> <p>Finally, one of the specific activity elements defined herein MAY itself contain a properly-namespaced child element that provides more detailed information about the specific activity. Here is an example:</p>
<code><![CDATA[ <code><![CDATA[
<activity xmlns='http://jabber.org/protocol/activity'> <activity xmlns='http://jabber.org/protocol/activity'>
@ -105,7 +105,7 @@
</sleeping> </sleeping>
</inactive> </inactive>
</activity> </activity>
]]></code> ]]></code>
<p>In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.</p> <p>In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.</p>
</section2> </section2>
<section2 topic='Pubsub Transport' anchor='proto-pubsub'> <section2 topic='Pubsub Transport' anchor='proto-pubsub'>
@ -127,7 +127,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The activity is then delivered to all subscribers:</p> <p>The activity is then delivered to all subscribers:</p>
<example caption='Activity is Delivered to All Subscribers'><![CDATA[ <example caption='Activity is Delivered to All Subscribers'><![CDATA[
<message <message
@ -146,7 +146,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>In order to indicate that the user is no longer publishing activities, the user's client shall send an empty &lt;activity/&gt; element, which can be considered a "stop command" for user activities:</p> <p>In order to indicate that the user is no longer publishing activities, the user's client shall send an empty &lt;activity/&gt; element, which can be considered a "stop command" for user activities:</p>
<example caption='User Disables Publishing'><![CDATA[ <example caption='User Disables Publishing'><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
@ -160,7 +160,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Empty Activity Information is Delivered to All Subscribers'><![CDATA[ <example caption='Empty Activity Information is Delivered to All Subscribers'><![CDATA[
<message <message
from='juliet@capulet.lit' from='juliet@capulet.lit'
@ -173,7 +173,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Activity Values' anchor='activities'> <section1 topic='Activity Values' anchor='activities'>
@ -512,6 +512,6 @@
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0109.xml
View File

@ -128,7 +128,7 @@
<items node='urn:xmpp:ooo:0'/> <items node='urn:xmpp:ooo:0'/>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server returns out-of-office settings'><![CDATA[ <example caption='Server returns out-of-office settings'><![CDATA[
<iq type='result' <iq type='result'
@ -148,7 +148,7 @@
</items> </items>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The &lt;start/> and &lt;end/> elements define the times between which this vacation <p>The &lt;start/> and &lt;end/> elements define the times between which this vacation
message should be considered valid by a supporting client; the times are in message should be considered valid by a supporting client; the times are in
@ -162,7 +162,7 @@
<example caption='User does not have any out-of-office settings'><![CDATA[ <example caption='User does not have any out-of-office settings'><![CDATA[
<iq type='result' id='get1'/> <iq type='result' id='get1'/>
]]></example> ]]></example>
</section2> </section2>
@ -190,7 +190,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Out-of-office settings published successfully'><![CDATA[ <example caption='Out-of-office settings published successfully'><![CDATA[
<iq type='result' <iq type='result'
@ -233,7 +233,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>The meaning of each element is as outlined above. All elements are required.</p> <p>The meaning of each element is as outlined above. All elements are required.</p>
@ -260,14 +260,14 @@
</retract> </retract>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Vacation settings removed successfully'><![CDATA[ <example caption='Vacation settings removed successfully'><![CDATA[
<iq type='result' <iq type='result'
from='example.com' from='example.com'
to='user@example.com/client' to='user@example.com/client'
id='retract1' /> id='retract1' />
]]></example> ]]></example>
<p>TODO: Is the Delete And Notify functionality described in XEP-0060 <p>TODO: Is the Delete And Notify functionality described in XEP-0060
7.2.2.1 widely implemented? If so, should that case be included here?</p> 7.2.2.1 widely implemented? If so, should that case be included here?</p>
@ -340,7 +340,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

6
xep-0110.xml
View File

@ -72,7 +72,7 @@
<desc>ortho_0.gif - map for map1.ygf</desc> <desc>ortho_0.gif - map for map1.ygf</desc>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>Each map consists of one or more layers. The main purpose of layers is to combine maps and views to deliver information suitable for a particular context, and to offer greater flexibility to the user in respect to customization.</p> <p>Each map consists of one or more layers. The main purpose of layers is to combine maps and views to deliver information suitable for a particular context, and to offer greater flexibility to the user in respect to customization.</p>
<p>Layers can be defined either inline or by a reference to another map. Each layer has a specified position in the map, a scale and a priority. The maps defined inline contain also projection, underlying image and a list of entities lying inside it (i.e. typically JIDs or clusters of JIDs). The underlying images are sent out of band using the jabber:x:oob namespace or possibly defined in some other way (e.g. xml-based SVG).</p> <p>Layers can be defined either inline or by a reference to another map. Each layer has a specified position in the map, a scale and a priority. The maps defined inline contain also projection, underlying image and a list of entities lying inside it (i.e. typically JIDs or clusters of JIDs). The underlying images are sent out of band using the jabber:x:oob namespace or possibly defined in some other way (e.g. xml-based SVG).</p>
<p>The map in Example 1 uses an implicit map projection assuming that attributes x and y are directly the co-ordinates of a particular entity (e.g. buddy1@jabber.org) in the image (ortho_0.gif) expressed in pixels.</p> <p>The map in Example 1 uses an implicit map projection assuming that attributes x and y are directly the co-ordinates of a particular entity (e.g. buddy1@jabber.org) in the image (ortho_0.gif) expressed in pixels.</p>
@ -88,7 +88,7 @@
<item jid='buddy2@jabber.org' long='12' lat='52'/> <item jid='buddy2@jabber.org' long='12' lat='52'/>
</layer> </layer>
</map> </map>
]]></example> ]]></example>
<p>As can be seen in Example 2, the projection can be specified using any parameters either explicitly set in the item tags or obtained for the particular JID from some other source (e.g. JUD or LDAP).</p> <p>As can be seen in Example 2, the projection can be specified using any parameters either explicitly set in the item tags or obtained for the particular JID from some other source (e.g. JUD or LDAP).</p>
</section2> </section2>
<section2 topic='Scaleability'> <section2 topic='Scaleability'>
@ -104,7 +104,7 @@
</cluster> </cluster>
</layer> </layer>
</map> </map>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes'> <section1 topic='Implementation Notes'>

18
xep-0111.xml
View File

@ -143,7 +143,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 2: B tells A that it is trying'><![CDATA[ <example caption='Step 2: B tells A that it is trying'><![CDATA[
<message <message
from='B@example.com/laptop' from='B@example.com/laptop'
@ -162,7 +162,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 3: B tells A that it is ringing'><![CDATA[ <example caption='Step 3: B tells A that it is ringing'><![CDATA[
<message <message
from='B@example.com/laptop' from='B@example.com/laptop'
@ -180,7 +180,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 4: B sends an updated description to A'><![CDATA[ <example caption='Step 4: B sends an updated description to A'><![CDATA[
<message <message
from='B@example.com/laptop' from='B@example.com/laptop'
@ -214,7 +214,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 5: A sends an acknowledgement to B'><![CDATA[ <example caption='Step 5: A sends an acknowledgement to B'><![CDATA[
<message <message
from='A@example.com/work' from='A@example.com/work'
@ -231,7 +231,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 6: B hangs up'><![CDATA[ <example caption='Step 6: B hangs up'><![CDATA[
<message <message
from='B@example.com/laptop' from='B@example.com/laptop'
@ -248,7 +248,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
<example caption='Step 7: A acknowledges the hang up'><![CDATA[ <example caption='Step 7: A acknowledges the hang up'><![CDATA[
<message <message
from='A@example.com/work' from='A@example.com/work'
@ -267,7 +267,7 @@
<address type='bcc' jid='compliance.example.com'/> <address type='bcc' jid='compliance.example.com'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<p><em>More examples to follow.</em></p> <p><em>More examples to follow.</em></p>
</section1> </section1>
@ -313,7 +313,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='sdp' anchor='schema-sdp'> <section2 topic='sdp' anchor='schema-sdp'>
<code><![CDATA[ <code><![CDATA[
@ -328,7 +328,7 @@
<xs:element name='sdp' type='xs:string'/> <xs:element name='sdp' type='xs:string'/>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

8
xep-0112.xml
View File

@ -119,7 +119,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The location information is then delivered to all subscribers:</p> <p>The location information is then delivered to all subscribers:</p>
<example caption='Address is Delivered to All Subscribers'><![CDATA[ <example caption='Address is Delivered to All Subscribers'><![CDATA[
<message <message
@ -142,7 +142,7 @@
. .
. .
. .
]]></example> ]]></example>
<p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p> <p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p>
<example caption='Event notification with extended stanza addressing'><![CDATA[ <example caption='Event notification with extended stanza addressing'><![CDATA[
<message <message
@ -165,7 +165,7 @@
<address type='replyto' jid='stpeter@jabber.org'/> <address type='replyto' jid='stpeter@jabber.org'/>
</addresses> </addresses>
</message> </message>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Mapping to Other Formats' anchor='mapping'> <section1 topic='Mapping to Other Formats' anchor='mapping'>
<p>There are many XML data formats for physical location or address information. It is beyond the scope of this document to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:</p> <p>There are many XML data formats for physical location or address information. It is beyond the scope of this document to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:</p>
@ -307,6 +307,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

20
xep-0113.xml
View File

@ -79,7 +79,7 @@
<path d='M 100 100 L 300 100 200 300 100 100' stroke='#ff0000' stroke-width='1' id='painter1'/> <path d='M 100 100 L 300 100 200 300 100 100' stroke='#ff0000' stroke-width='1' id='painter1'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>The path node is a simplified SVG path node that allows only 'M', 'm', 'L' and 'l' commands. 'M' ('m') command is a (relative) moveto command, 'L' ('l') is a (relative) lineto command. All four commands take one or more coordinate pairs (in pixels). 'M' sets the current point to the coordinate pair. 'm' adds the coordinate pair to the current point. 'L' draws a line from the current point to the point designated by the coordinate pair and sets the current point to the coordinate pair. 'l' draws a line from the current point to the sum of the currentpoint and the coordinate pair and adds the coordinate pair to the current point. The optional stroke attribute indicates the color of the path and defaults to black, the optional stroke-width indicates the width of the path in pixels and defaults to 1. The id attribute can be used for later reference to the path. If there is no id attribute, the path can not be referred to.</p> <p>The path node is a simplified SVG path node that allows only 'M', 'm', 'L' and 'l' commands. 'M' ('m') command is a (relative) moveto command, 'L' ('l') is a (relative) lineto command. All four commands take one or more coordinate pairs (in pixels). 'M' sets the current point to the coordinate pair. 'm' adds the coordinate pair to the current point. 'L' draws a line from the current point to the point designated by the coordinate pair and sets the current point to the coordinate pair. 'l' draws a line from the current point to the sum of the currentpoint and the coordinate pair and adds the coordinate pair to the current point. The optional stroke attribute indicates the color of the path and defaults to black, the optional stroke-width indicates the width of the path in pixels and defaults to 1. The id attribute can be used for later reference to the path. If there is no id attribute, the path can not be referred to.</p>
<p>The path in example 1, draws a red triangle with vertices (100,100), (300,100) and (200, 300)</p> <p>The path in example 1, draws a red triangle with vertices (100,100), (300,100) and (200, 300)</p>
<p>Other respresentations of the same path are 'M100.0,100.0L300.0,100.0,200.0,300.0,100.0,100.0', 'M100,100l200,0-100,200-100-200' and 'M100,100l200,0L200,300,100,100'. Note that in the second representation some commas can be left out because the sign indicates that a new coordinate is starting. This fact can be used to reduce data size as much as possible to avoid karma problems. A precise grammar of the "d" attribute is given below.</p> <p>Other respresentations of the same path are 'M100.0,100.0L300.0,100.0,200.0,300.0,100.0,100.0', 'M100,100l200,0-100,200-100-200' and 'M100,100l200,0L200,300,100,100'. Note that in the second representation some commas can be left out because the sign indicates that a new coordinate is starting. This fact can be used to reduce data size as much as possible to avoid karma problems. A precise grammar of the "d" attribute is given below.</p>
@ -98,7 +98,7 @@
<path d='M100.0,100.0L300.0,100.0,200.0,300.0,100.0,100.0' id='kingclaudius1' /> <path d='M100.0,100.0L300.0,100.0,200.0,300.0,100.0,100.0' id='kingclaudius1' />
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>In this case the dialog will not close. At the destination client a similar dialog will pop up, allowing the user at the other end to add her own part of the drawing. The resulting message will look like this (line breaks provided for readability only):</p> <p>In this case the dialog will not close. At the destination client a similar dialog will pop up, allowing the user at the other end to add her own part of the drawing. The resulting message will look like this (line breaks provided for readability only):</p>
<example caption='Continuing a whiteboard chat session'><![CDATA[ <example caption='Continuing a whiteboard chat session'><![CDATA[
<message <message
@ -131,7 +131,7 @@
58 117 56 117 55 117 54 117' /> 58 117 56 117 55 117 54 117' />
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>It is left as a mental exercise to the reader to imagine Laertes answer. Alternatively the reader could build this protocol into her favorite Jabber client, set a breakpoint, and paste the path above at the appropriate place.</p> <p>It is left as a mental exercise to the reader to imagine Laertes answer. Alternatively the reader could build this protocol into her favorite Jabber client, set a breakpoint, and paste the path above at the appropriate place.</p>
<p>Alternatively Laertes could respond like:</p> <p>Alternatively Laertes could respond like:</p>
<example caption='Moving a path'><![CDATA[ <example caption='Moving a path'><![CDATA[
@ -144,7 +144,7 @@
<move id='kingclaudius1' dx='-100' dy='-100'/> <move id='kingclaudius1' dx='-100' dy='-100'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>This would move the King's triangle 100 pixels to the left and top, to the upper left corner of the screen.</p> <p>This would move the King's triangle 100 pixels to the left and top, to the upper left corner of the screen.</p>
<p>If Laertes were bold enough he might even answer:</p> <p>If Laertes were bold enough he might even answer:</p>
<example caption='Deleting a path'><![CDATA[ <example caption='Deleting a path'><![CDATA[
@ -157,7 +157,7 @@
<delete id='kingclaudius1'/> <delete id='kingclaudius1'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>This would remove King Claudius's triangle from the screen.</p> <p>This would remove King Claudius's triangle from the screen.</p>
</section2> </section2>
<section2 topic='Conference room whiteboard'> <section2 topic='Conference room whiteboard'>
@ -172,7 +172,7 @@
<path d='M100,100l200,0L200,300,100,100' /> <path d='M100,100l200,0L200,300,100,100' />
</x> </x>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes'> <section1 topic='Implementation Notes'>
@ -209,7 +209,7 @@
currentPathSet.back ().push_back (myPoint); // pen is down add a new point to the latest path currentPathSet.back ().push_back (myPoint); // pen is down add a new point to the latest path
} }
} }
]]></example> ]]></example>
<p>The string 'Jabber' would be encoded as the path 'M24 59l0,16-1,3-1,1-2,1-2,0-2-1-1-1-1-3 0-2M43 66l0,14M43 69l-2-2-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M51 59l0,21M51 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M70 59l0,21M70 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M88 72l12,0 0-2-1-2-1-1-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M107 66l0,14M107 72l1-3 2-2 2-1 3,0', which is 357 characters long. That is no more than twice the size of a typical groupchat text message. </p> <p>The string 'Jabber' would be encoded as the path 'M24 59l0,16-1,3-1,1-2,1-2,0-2-1-1-1-1-3 0-2M43 66l0,14M43 69l-2-2-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M51 59l0,21M51 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M70 59l0,21M70 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M88 72l12,0 0-2-1-2-1-1-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M107 66l0,14M107 72l1-3 2-2 2-1 3,0', which is 357 characters long. That is no more than twice the size of a typical groupchat text message. </p>
</section2> </section2>
<section2 topic='Clearing the screen'> <section2 topic='Clearing the screen'>
@ -268,7 +268,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='DTD'> <section2 topic='DTD'>
<code><![CDATA[ <code><![CDATA[
@ -285,7 +285,7 @@
dy CDATA #REQUIRED > dy CDATA #REQUIRED >
<!ELEMENT delete EMPTY > <!ELEMENT delete EMPTY >
<!ATTLIST delete id CDATA #REQUIRED > <!ATTLIST delete id CDATA #REQUIRED >
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Grammar of "d" attribute'> <section2 topic='Grammar of "d" attribute'>
<p>The grammar of the "d" attribute below is a slight simplification of section 8.3.9 in <note>Scalable Vector Graphics (SVG) 1.0 Specification, section 8.3.1.: The grammar for path data <link url="http://www.w3.org/TR/SVG/paths.html#PathDataBNF">http://www.w3.org/TR/SVG/paths.html#PathDataBNF</link></note>.</p> <p>The grammar of the "d" attribute below is a slight simplification of section 8.3.9 in <note>Scalable Vector Graphics (SVG) 1.0 Specification, section 8.3.1.: The grammar for path data <link url="http://www.w3.org/TR/SVG/paths.html#PathDataBNF">http://www.w3.org/TR/SVG/paths.html#PathDataBNF</link></note>.</p>
@ -371,7 +371,7 @@
wsp: wsp:
(#x20 | #x9 | #xD | #xA) (#x20 | #x9 | #xD | #xA)
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='Conclusion'> <section1 topic='Conclusion'>

12
xep-0114.xml
View File

@ -91,7 +91,7 @@
xmlns='jabber:component:accept' xmlns='jabber:component:accept'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='plays.shakespeare.lit'> to='plays.shakespeare.lit'>
]]></example> ]]></example>
<p>Note: In the 'jabber:component:accept' namespace, the value of the 'to' address is the component name, not the server name; <note>In the 'jabber:component:connect' namespace, the server would set the 'from' attribute to the component name.</note> this enables the server to determine whether it will service a component of that name (e.g., based on server configuration or some other implementation-specific mechanism). If so, the server MUST reply with a stream header.</p> <p>Note: In the 'jabber:component:accept' namespace, the value of the 'to' address is the component name, not the server name; <note>In the 'jabber:component:connect' namespace, the server would set the 'from' attribute to the component name.</note> this enables the server to determine whether it will service a component of that name (e.g., based on server configuration or some other implementation-specific mechanism). If so, the server MUST reply with a stream header.</p>
<example caption='Server replies with stream header, including StreamID'><![CDATA[ <example caption='Server replies with stream header, including StreamID'><![CDATA[
<stream:stream <stream:stream
@ -99,12 +99,12 @@
xmlns='jabber:component:accept' xmlns='jabber:component:accept'
from='plays.shakespeare.lit' from='plays.shakespeare.lit'
id='3BF96D32'> id='3BF96D32'>
]]></example> ]]></example>
<p>If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., &lt;conflict/&gt; or &lt;host-unknown/&gt;). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an &lt;invalid-namespace/&gt; stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of <cite>XMPP Core</cite> by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to <cite>RFC 3920</cite> for details).</p> <p>If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., &lt;conflict/&gt; or &lt;host-unknown/&gt;). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an &lt;invalid-namespace/&gt; stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of <cite>XMPP Core</cite> by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to <cite>RFC 3920</cite> for details).</p>
<p>After receiving the stream header reply from the server, the component MUST send a &lt;handshake/&gt; element with appropriate contents. <note>The handshake value is always supplied by the initiator. Thus for jabber:component:accept connections, the handshake value is provided by the component, whereas for jabber:component:connect connections, the handshake value is provided by the server.</note></p> <p>After receiving the stream header reply from the server, the component MUST send a &lt;handshake/&gt; element with appropriate contents. <note>The handshake value is always supplied by the initiator. Thus for jabber:component:accept connections, the handshake value is provided by the component, whereas for jabber:component:connect connections, the handshake value is provided by the server.</note></p>
<example caption='Component sends handshake element'><![CDATA[ <example caption='Component sends handshake element'><![CDATA[
<handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake> <handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake>
]]></example> ]]></example>
<p>The XML character data of the handshake element is computed according to the following algorithm:</p> <p>The XML character data of the handshake element is computed according to the following algorithm:</p>
<ol> <ol>
<li>Concatenate the Stream ID received from the server with the shared secret.</li> <li>Concatenate the Stream ID received from the server with the shared secret.</li>
@ -116,7 +116,7 @@
<p>If the credentials are acceptable, the receiving application (in this case the server) MUST return an empty &lt;handshake/&gt; element.</p> <p>If the credentials are acceptable, the receiving application (in this case the server) MUST return an empty &lt;handshake/&gt; element.</p>
<example caption='Server sends empty handshake element to acknowledge success'><![CDATA[ <example caption='Server sends empty handshake element to acknowledge success'><![CDATA[
<handshake/> <handshake/>
]]></example> ]]></example>
<p>Once authenticated, the component can send stanzas through the server and receive stanzas from the server. All stanzas sent to the server MUST possess a 'from' attribute and a 'to' attribute, as in the 'jabber:server' namespace. The domain identifier portion of the JID contained in the 'from' attribute MUST match the hostname of the component. However, this is the only restriction on 'from' addresses, and the component MAY send stanzas from any user at its hostname.</p> <p>Once authenticated, the component can send stanzas through the server and receive stanzas from the server. All stanzas sent to the server MUST possess a 'from' attribute and a 'to' attribute, as in the 'jabber:server' namespace. The domain identifier portion of the JID contained in the 'from' attribute MUST match the hostname of the component. However, this is the only restriction on 'from' addresses, and the component MAY send stanzas from any user at its hostname.</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
@ -335,7 +335,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='jabber:component:connect' anchor='schema-connect'> <section2 topic='jabber:component:connect' anchor='schema-connect'>
<code><![CDATA[ <code><![CDATA[
@ -543,7 +543,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

30
xep-0115.xml
View File

@ -155,7 +155,7 @@
node='http://code.google.com/p/exodus' node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence> </presence>
]]></code> ]]></code>
<p>The 'node' attribute represents the client software Romeo is using. The 'ver' attribute is a specially-constructed string (called a "verification string") that represents the entity's service discovery identity (category and type as registered at &DISCOCATEGORIES;, as well as, optionally, xml:lang and name) and supported features (as registered at &DISCOFEATURES; as well as, optionally, extended service discovery information data registered at &FORMTYPES;).</p> <p>The 'node' attribute represents the client software Romeo is using. The 'ver' attribute is a specially-constructed string (called a "verification string") that represents the entity's service discovery identity (category and type as registered at &DISCOCATEGORIES;, as well as, optionally, xml:lang and name) and supported features (as registered at &DISCOFEATURES; as well as, optionally, extended service discovery information data registered at &FORMTYPES;).</p>
<p>At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.</p> <p>At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.</p>
<code><![CDATA[ <code><![CDATA[
@ -166,7 +166,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/> node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
</iq> </iq>
]]></code> ]]></code>
<p>The response is:</p> <p>The response is:</p>
<code><![CDATA[ <code><![CDATA[
<iq from='romeo@montague.lit/orchard' <iq from='romeo@montague.lit/orchard'
@ -182,7 +182,7 @@
<feature var='http://jabber.org/protocol/muc'/> <feature var='http://jabber.org/protocol/muc'/>
</query> </query>
</iq> </iq>
]]></code> ]]></code>
<p>At this point, your client knows that a contact who advertises a verification string of 'QgayPKawpkPSDYmwT/WM94uAlu0=' supports &xep0045; and the other features returned by Romeo because the contact in fact uses the same version of the same client software as Romeo, with the same enabled features, plugins, presented client name(s), and the like (i.e., the same input to the verification string <link url='#ver-gen'>generation method</link>). <note>The string can be relied upon because of how it is generated and checked, as explained later in this document.</note> Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same verification string. For example, your Nurse may use the same client that Romeo does:</p> <p>At this point, your client knows that a contact who advertises a verification string of 'QgayPKawpkPSDYmwT/WM94uAlu0=' supports &xep0045; and the other features returned by Romeo because the contact in fact uses the same version of the same client software as Romeo, with the same enabled features, plugins, presented client name(s), and the like (i.e., the same input to the verification string <link url='#ver-gen'>generation method</link>). <note>The string can be relied upon because of how it is generated and checked, as explained later in this document.</note> Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same verification string. For example, your Nurse may use the same client that Romeo does:</p>
<code><![CDATA[ <code><![CDATA[
<presence from='nurse@capulet.lit/chamber'> <presence from='nurse@capulet.lit/chamber'>
@ -191,7 +191,7 @@
node='http://code.google.com/p/exodus' node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence> </presence>
]]></code> ]]></code>
<p>Therefore you know that she also supports the same features that Romeo does.</p> <p>Therefore you know that she also supports the same features that Romeo does.</p>
<p>On the other hand, for a person with the following presence ...</p> <p>On the other hand, for a person with the following presence ...</p>
<code><![CDATA[ <code><![CDATA[
@ -201,7 +201,7 @@
node='http://psi-im.org' node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/> ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
</presence> </presence>
]]></code> ]]></code>
<p>... or the following presence ...</p> <p>... or the following presence ...</p>
<code><![CDATA[ <code><![CDATA[
<presence from='bard@shakespeare.lit/globe'> <presence from='bard@shakespeare.lit/globe'>
@ -210,7 +210,7 @@
node='http://www.chatopus.com' node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/> ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
</presence> </presence>
]]></code> ]]></code>
<p>... you have no information about what this contact's client is capable of unless you have cached previous entity capabilities information; therefore you need to query for capabilities explicitly again via service discovery.</p> <p>... you have no information about what this contact's client is capable of unless you have cached previous entity capabilities information; therefore you need to query for capabilities explicitly again via service discovery.</p>
</section2> </section2>
</section1> </section1>
@ -444,7 +444,7 @@
node='http://code.google.com/p/exodus' node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence> </presence>
]]></example> ]]></example>
<p>If the supported features change during a generating entity's presence session (e.g., a user installs an updated version of a client plugin), the application MUST recompute the verification string and SHOULD send a new presence broadcast.</p> <p>If the supported features change during a generating entity's presence session (e.g., a user installs an updated version of a client plugin), the application MUST recompute the verification string and SHOULD send a new presence broadcast.</p>
<example caption='Presence with recomputed ver attribute'><![CDATA[ <example caption='Presence with recomputed ver attribute'><![CDATA[
<presence> <presence>
@ -453,7 +453,7 @@
node='http://code.google.com/p/exodus' node='http://code.google.com/p/exodus'
ver='66/0NaeaBKkwk85efJTGmU47vXI='/> ver='66/0NaeaBKkwk85efJTGmU47vXI='/>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Discovering Capabilities" anchor='discover'> <section2 topic="Discovering Capabilities" anchor='discover'>
@ -467,7 +467,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/> node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
</iq> </iq>
]]></example> ]]></example>
<p>The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID &LOCALFULL;.</p> <p>The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID &LOCALFULL;.</p>
<p>Note: The generating entity SHOULD NOT include the "caps node" in the list of entities it returns in its disco#items responses; i.e., the caps node is a kind of virtual or phantom node, not a true items node that is associated with the generating entity for service discovery purposes.</p> <p>Note: The generating entity SHOULD NOT include the "caps node" in the list of entities it returns in its disco#items responses; i.e., the caps node is a kind of virtual or phantom node, not a true items node that is associated with the generating entity for service discovery purposes.</p>
@ -488,7 +488,7 @@
<feature var='http://jabber.org/protocol/muc'/> <feature var='http://jabber.org/protocol/muc'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the generating entity incorporated multiple identities with different xml:lang values in its verification string, it MUST return all of the identities even if the request specified a particular xml:lang.</p> <p>Note: If the generating entity incorporated multiple identities with different xml:lang values in its verification string, it MUST return all of the identities even if the request specified a particular xml:lang.</p>
@ -503,7 +503,7 @@
node='http://jabberd.org' node='http://jabberd.org'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/> ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features> </stream:features>
]]></example> ]]></example>
<p>When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with <cite>RFC 6120</cite>.</p> <p>When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with <cite>RFC 6120</cite>.</p>
</section2> </section2>
</section1> </section1>
@ -517,7 +517,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service discovery information response"><![CDATA[ <example caption="Service discovery information response"><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
id='disco2' id='disco2'
@ -529,7 +529,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If a server supports the <link url='#impl-optimize'>Caps Optimization</link> functionality, it MUST also return a feature of <strong>'http://jabber.org/protocol/caps#optimize'</strong> in response to service discovery information requests.</p> <p>If a server supports the <link url='#impl-optimize'>Caps Optimization</link> functionality, it MUST also return a feature of <strong>'http://jabber.org/protocol/caps#optimize'</strong> in response to service discovery information requests.</p>
<example caption="Service discovery information request"><![CDATA[ <example caption="Service discovery information request"><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
@ -538,7 +538,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service discovery information response"><![CDATA[ <example caption="Service discovery information response"><![CDATA[
<iq from='capulet.lit' <iq from='capulet.lit'
id='disco3' id='disco3'
@ -550,7 +550,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>

30
xep-0116.xml
View File

@ -161,7 +161,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>If Bob sends a disco#info reply and he supports the protocol defined herein, then he MUST include a service discovery feature variable of "http://www.xmpp.org/extensions/xep-0116.html#ns" &NSNOTE;.</p> <p>If Bob sends a disco#info reply and he supports the protocol defined herein, then he MUST include a service discovery feature variable of "http://www.xmpp.org/extensions/xep-0116.html#ns" &NSNOTE;.</p>
<example caption='Bob Returns disco#info Data'><![CDATA[ <example caption='Bob Returns disco#info Data'><![CDATA[
<iq type='result' <iq type='result'
@ -175,7 +175,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic="Online ESession Negotiation" anchor='init'> <section1 topic="Online ESession Negotiation" anchor='init'>
@ -308,7 +308,7 @@
<rule action='drop' condition='deliver' value='stored'/> <rule action='drop' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
<p>The first message of a 3-message negotiation is identical except there MUST be no 'sas_algs' field and a 'dhkeys' field MUST be included instead of the 'dhhashes' field:</p> <p>The first message of a 3-message negotiation is identical except there MUST be no 'sas_algs' field and a 'dhkeys' field MUST be included instead of the 'dhhashes' field:</p>
<example caption='Alice Initiates a 3-message ESession Negotiation'><![CDATA[ <example caption='Alice Initiates a 3-message ESession Negotiation'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com'> <message from='alice@example.org/pda' to='bob@example.com'>
@ -335,7 +335,7 @@
<rule action='drop' condition='deliver' value='stored'/> <rule action='drop' condition='deliver' value='stored'/>
</amp> </amp>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="ESession Rejection (Bob)" anchor='init-online-reject'> <section2 topic="ESession Rejection (Bob)" anchor='init-online-reject'>
@ -356,7 +356,7 @@
</feature> </feature>
</error> </error>
</message> </message>
]]></example> ]]></example>
<p>If Bob supports <em>none</em> of the options for one or more ESession fields, then he SHOULD return a &notacceptable; error specifying the field(s) with unsupported options:</p> <p>If Bob supports <em>none</em> of the options for one or more ESession fields, then he SHOULD return a &notacceptable; error specifying the field(s) with unsupported options:</p>
<example caption='Bob Informs Alice that Her Options are Not Supported'><![CDATA[ <example caption='Bob Informs Alice that Her Options are Not Supported'><![CDATA[
<message type='error' <message type='error'
@ -374,7 +374,7 @@
</feature> </feature>
</error> </error>
</message> </message>
]]></example> ]]></example>
<p>Either Bob or Alice MAY attempt to initiate a new ESession after any error during the negotiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.</p> <p>Either Bob or Alice MAY attempt to initiate a new ESession after any error during the negotiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.</p>
<p>If Bob is unwilling to start an ESession, but he <em>is</em> ready to initiate a one-to-one stanza session with Alice (see <cite>Stanza Session Negotiation</cite>), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the stanza session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.</p> <p>If Bob is unwilling to start an ESession, but he <em>is</em> ready to initiate a one-to-one stanza session with Alice (see <cite>Stanza Session Negotiation</cite>), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the stanza session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.</p>
<example caption='Bob Accepts Stanza Session'><![CDATA[ <example caption='Bob Accepts Stanza Session'><![CDATA[
@ -392,7 +392,7 @@
</x> </x>
</feature> </feature>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="ESession Response (Bob)" anchor='init-response'> <section2 topic="ESession Response (Bob)" anchor='init-response'>
@ -456,7 +456,7 @@
</x> </x>
</feature> </feature>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Generating Session Keys" anchor='init-keys'> <section3 topic="Generating Session Keys" anchor='init-keys'>
@ -532,7 +532,7 @@
</x> </x>
</feature> </feature>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
@ -602,7 +602,7 @@
<mac> ** Base64 encoded a_mac ** </mac> <mac> ** Base64 encoded a_mac ** </mac>
</c> </c>
</message> </message>
]]></example> ]]></example>
<p>Note: If Alice also includes a 'terminate' field with its value set to "1" or "true" (see <link url='#terminate'>ESession Termination</link>) within the form then the ESession is terminated immediately. Note: This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.</p> <p>Note: If Alice also includes a 'terminate' field with its value set to "1" or "true" (see <link url='#terminate'>ESession Termination</link>) within the form then the ESession is terminated immediately. Note: This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.</p>
<p>In the case of a 4-message negotiation Alice MUST also include in the data form her Base64 encoded values of e (wrapped in a 'dhkeys' field) and the Base64 encoded HMAC (using HASH and the key &NsubA; <note>The HMACs of the retained secrets are generated using Alice's unique session nonce to prevent her being identified by her retained secrets (only one secret changes each session, and some might not change very often).</note>) of each secret that Alice has retained from her previous session with each of Bob's clients (wrapped in a 'rshashes' field) - see <link url='#init-acceptbob-send'>Sending Bob's Identity</link>. Note: Alice MUST also append a few random numbers to the 'rshashes' field to make it difficult for an active attacker to discover if she has communicated with Bob before or how many clients Bob has used to communicate with her.</p> <p>In the case of a 4-message negotiation Alice MUST also include in the data form her Base64 encoded values of e (wrapped in a 'dhkeys' field) and the Base64 encoded HMAC (using HASH and the key &NsubA; <note>The HMACs of the retained secrets are generated using Alice's unique session nonce to prevent her being identified by her retained secrets (only one secret changes each session, and some might not change very often).</note>) of each secret that Alice has retained from her previous session with each of Bob's clients (wrapped in a 'rshashes' field) - see <link url='#init-acceptbob-send'>Sending Bob's Identity</link>. Note: Alice MUST also append a few random numbers to the 'rshashes' field to make it difficult for an active attacker to discover if she has communicated with Bob before or how many clients Bob has used to communicate with her.</p>
<example caption='Alice Sends Bob Her Identity (4-Message Negotiation)'><![CDATA[ <example caption='Alice Sends Bob Her Identity (4-Message Negotiation)'><![CDATA[
@ -627,7 +627,7 @@
</x> </x>
</feature> </feature>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
@ -684,7 +684,7 @@
</x> </x>
</init> </init>
</message> </message>
]]></example> ]]></example>
<p>Finally, Bob MUST destroy all his copies of the old retained secret (SRS) he was keeping for Alice's client, and calculate a new retained secret for this session:</p> <p>Finally, Bob MUST destroy all his copies of the old retained secret (SRS) he was keeping for Alice's client, and calculate a new retained secret for this session:</p>
<code><em>HMAC</em>(HASH, K, "New Retained Secret")</code> <code><em>HMAC</em>(HASH, K, "New Retained Secret")</code>
<p>Bob MUST <em>securely</em> store the new value along with the retained secrets his client shares with Alice's other clients.</p> <p>Bob MUST <em>securely</em> store the new value along with the retained secrets his client shares with Alice's other clients.</p>
@ -722,7 +722,7 @@
<mac> ** Base64 encoded a_mac ** </mac> <mac> ** Base64 encoded a_mac ** </mac>
</c> </c>
</message> </message>
]]></example> ]]></example>
<p>When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the ESession) and immediately send an encrypted termination acknowledgement form (as specified in the Termination section of <cite>Stanza Session Negotiation</cite>) back to Alice. Note: He MAY publish <em>any</em> old values of &KMsubA; or &KMsubB; within the acknowledgement stanza. He MUST then securely destroy all keys associated with the ESession.</p> <p>When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the ESession) and immediately send an encrypted termination acknowledgement form (as specified in the Termination section of <cite>Stanza Session Negotiation</cite>) back to Alice. Note: He MAY publish <em>any</em> old values of &KMsubA; or &KMsubB; within the acknowledgement stanza. He MUST then securely destroy all keys associated with the ESession.</p>
<example caption='Bob Acknowledges ESession Termination'><![CDATA[ <example caption='Bob Acknowledges ESession Termination'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'> <message from='bob@example.com/laptop' to='alice@example.org/pda'>
@ -733,7 +733,7 @@
<mac> ** Base64 encoded b_mac ** </mac> <mac> ** Base64 encoded b_mac ** </mac>
</c> </c>
</message> </message>
]]></example> ]]></example>
<p>When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the ESession. Once an entity has sent a termination or termination acknowledgement stanza it MUST NOT send another stanza within the ESession.</p> <p>When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the ESession. Once an entity has sent a termination or termination acknowledgement stanza it MUST NOT send another stanza within the ESession.</p>
</section1> </section1>
@ -1011,7 +1011,7 @@
<doc>XEP-0155</doc> <doc>XEP-0155</doc>
... ...
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

10
xep-0118.xml
View File

@ -183,7 +183,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The tune information is then delivered to all subscribers:</p> <p>The tune information is then delivered to all subscribers:</p>
<example caption='Tune Information is Delivered to All Subscribers'><![CDATA[ <example caption='Tune Information is Delivered to All Subscribers'><![CDATA[
<message <message
@ -205,7 +205,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>In order to indicate that the user is no longer listening to any tunes (or has simply disabled publication), the user's client shall send an empty &lt;tune/&gt; element, which can be considered a "stop command" for user tunes:</p> <p>In order to indicate that the user is no longer listening to any tunes (or has simply disabled publication), the user's client shall send an empty &lt;tune/&gt; element, which can be considered a "stop command" for user tunes:</p>
<example caption='User Disables Publishing'><![CDATA[ <example caption='User Disables Publishing'><![CDATA[
<iq type='set' <iq type='set'
@ -219,7 +219,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Empty Tune Information is Delivered to All Subscribers'><![CDATA[ <example caption='Empty Tune Information is Delivered to All Subscribers'><![CDATA[
<message <message
from='stpeter@jabber.org' from='stpeter@jabber.org'
@ -232,7 +232,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -289,6 +289,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0120.xml
View File

@ -86,7 +86,7 @@
<bundle type='http://jabber.org/protocol/infobits/bundles/geoloc'/> <bundle type='http://jabber.org/protocol/infobits/bundles/geoloc'/>
</info> </info>
</iq> </iq>
]]></example> ]]></example>
<example caption='Entity Returns Geolocation Result'><![CDATA[ <example caption='Entity Returns Geolocation Result'><![CDATA[
<iq type='result' <iq type='result'
from='stpeter@jabber.org' from='stpeter@jabber.org'
@ -103,7 +103,7 @@
</bundle> </bundle>
</info> </info>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Requesting All Infobits From Another Entity'> <section2 topic='Requesting All Infobits From Another Entity'>
<example caption='Requestor Requests Information'><![CDATA[ <example caption='Requestor Requests Information'><![CDATA[
@ -113,7 +113,7 @@
id='all1'> id='all1'>
<info xmlns='http://jabber.org/protocol/infobits'/> <info xmlns='http://jabber.org/protocol/infobits'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Entity Returns Information Result'><![CDATA[ <example caption='Entity Returns Information Result'><![CDATA[
<iq type='result' <iq type='result'
from='stpeter@jabber.org' from='stpeter@jabber.org'
@ -170,7 +170,7 @@
</bundle> </bundle>
</info> </info>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Publishing Tune Information'> <section2 topic='Publishing Tune Information'>
<p>This set of examples is borrowed from &xep0118;.</p> <p>This set of examples is borrowed from &xep0118;.</p>
@ -195,7 +195,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Tune Information is Delivered to All Subscribers'><![CDATA[ <example caption='Tune Information is Delivered to All Subscribers'><![CDATA[
<message <message
from='pubsub.jabber.org' from='pubsub.jabber.org'
@ -216,7 +216,7 @@
</items> </items>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>
@ -253,7 +253,7 @@
<value>second value</value> <value>second value</value>
</values> </values>
</bit> </bit>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema'> <section1 topic='XML Schema'>
@ -296,7 +296,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Historical Note'> <section1 topic='Historical Note'>
<p>Before defining a new protocol for metadata, the primary author of this proposal investigated several promising technologies that could be used to meet the above requirements -- in particular, the Friend of a Friend (FOAF) vocabulary, which is a subset of the Resource Description Framework (RDF). Ultimately, the primary author concluded that, while FOAF and RDF have many merits, they are not ideal for use on the Jabber network. In particular:</p> <p>Before defining a new protocol for metadata, the primary author of this proposal investigated several promising technologies that could be used to meet the above requirements -- in particular, the Friend of a Friend (FOAF) vocabulary, which is a subset of the Resource Description Framework (RDF). Ultimately, the primary author concluded that, while FOAF and RDF have many merits, they are not ideal for use on the Jabber network. In particular:</p>

6
xep-0121.xml
View File

@ -87,7 +87,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The following is an example of metadata for a conference room.</p> <p>The following is an example of metadata for a conference room.</p>
<example caption='Metadata Result from a Conference Room'><![CDATA[ <example caption='Metadata Result from a Conference Room'><![CDATA[
<iq type='result' <iq type='result'
@ -103,7 +103,7 @@
</info> </info>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>
<p>This document introduces no security considerations above and beyond those already defined in XEP-0120.</p> <p>This document introduces no security considerations above and beyond those already defined in XEP-0120.</p>
@ -191,6 +191,6 @@
<bit key='DC.PhysicalObject'/> <bit key='DC.PhysicalObject'/>
<bit key='DC.StillImage'/> <bit key='DC.StillImage'/>
<bit key='DC.MovingImage'/> <bit key='DC.MovingImage'/>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

24
xep-0122.xml
View File

@ -104,7 +104,7 @@
datatype='xs:dateTime'/> datatype='xs:dateTime'/>
<value>2003-10-06T11:22:00-07:00</value> <value>2003-10-06T11:22:00-07:00</value>
</field> </field>
]]></example> ]]></example>
<p>The preceding example demonstrates a field that is expected to contain a date/time value.</p> <p>The preceding example demonstrates a field that is expected to contain a date/time value.</p>
<p>The 'datatype' attribute specifies the datatype. This attribute is OPTIONAL, and defaults to "xs:string". It MUST meet one of the following conditions:</p> <p>The 'datatype' attribute specifies the datatype. This attribute is OPTIONAL, and defaults to "xs:string". It MUST meet one of the following conditions:</p>
<ul> <ul>
@ -133,7 +133,7 @@
</validate> </validate>
<value>2003-10-06T11:22:00-07:00</value> <value>2003-10-06T11:22:00-07:00</value>
</field> </field>
]]></example> ]]></example>
<p>Using &lt;basic/&gt; validation, the form interpreter MUST follow the validation rules of the datatype (if understood) and the field type.</p> <p>Using &lt;basic/&gt; validation, the form interpreter MUST follow the validation rules of the datatype (if understood) and the field type.</p>
<p>The &lt;basic/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p> <p>The &lt;basic/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p>
</section3> </section3>
@ -151,7 +151,7 @@
<option><value>reminder</value></option> <option><value>reminder</value></option>
<option><value>appointment</value></option> <option><value>appointment</value></option>
</field> </field>
]]></example> ]]></example>
<p>The &lt;open/&gt; validation method applies to "text-multi" differently; it hints that each value for a "text-multi" field shall be validated separately. This effectively turns "text-multi" fields into an open-ended "list-multi", with no options and all values automatically selected.</p> <p>The &lt;open/&gt; validation method applies to "text-multi" differently; it hints that each value for a "text-multi" field shall be validated separately. This effectively turns "text-multi" fields into an open-ended "list-multi", with no options and all values automatically selected.</p>
<p>The &lt;open/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p> <p>The &lt;open/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p>
</section3> </section3>
@ -166,7 +166,7 @@
</validate> </validate>
<value>2003-10-06T11:22:00-07:00</value> <value>2003-10-06T11:22:00-07:00</value>
</field> </field>
]]></example> ]]></example>
<p>The 'min' and 'max' attributes of the &lt;range/&gt; element specify the minimum and maximum values allowed, respectively.</p> <p>The 'min' and 'max' attributes of the &lt;range/&gt; element specify the minimum and maximum values allowed, respectively.</p>
<p>The 'max' attribute specifies the maximum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p> <p>The 'max' attribute specifies the maximum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p>
<p>The 'min' attribute specifies the minimum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p> <p>The 'min' attribute specifies the minimum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p>
@ -183,7 +183,7 @@
<regex>([0-9]{3})-([0-9]{2})-([0-9]{4})</regex> <regex>([0-9]{3})-([0-9]{2})-([0-9]{4})</regex>
</validate> </validate>
</field> </field>
]]></example> ]]></example>
<p>The XML character data of this element is the pattern to apply. The syntax of this content MUST be that defined for POSIX extended regular expressions<note>The "best" definition of this syntax can be found in the <link url='http://www.gsp.com/cgi-bin/man.cgi?section=7&amp;topic=re_format'>re_format(7) man page</link></note>, including support for Unicode<note>Guidelines for adapting regular expressions to support Unicode is defined at <link url='http://www.unicode.org/reports/tr18/'>http://www.unicode.org/reports/tr18/</link></note>.</p> <p>The XML character data of this element is the pattern to apply. The syntax of this content MUST be that defined for POSIX extended regular expressions<note>The "best" definition of this syntax can be found in the <link url='http://www.gsp.com/cgi-bin/man.cgi?section=7&amp;topic=re_format'>re_format(7) man page</link></note>, including support for Unicode<note>Guidelines for adapting regular expressions to support Unicode is defined at <link url='http://www.unicode.org/reports/tr18/'>http://www.unicode.org/reports/tr18/</link></note>.</p>
<p>The &lt;regex/&gt; element MUST contain character data only (i.e., not contain any child elements) and MUST NOT possess any attributes.</p> <p>The &lt;regex/&gt; element MUST contain character data only (i.e., not contain any child elements) and MUST NOT possess any attributes.</p>
</section3> </section3>
@ -205,7 +205,7 @@
<option><value>home phone</value></option> <option><value>home phone</value></option>
<option><value>cell phone</value></option> <option><value>cell phone</value></option>
</field> </field>
]]></example> ]]></example>
<p>The &lt;list-range/&gt; element SHOULD be included only when the &lt;field/&gt; is of type "list-multi" and SHOULD be ignored otherwise.</p> <p>The &lt;list-range/&gt; element SHOULD be included only when the &lt;field/&gt; is of type "list-multi" and SHOULD be ignored otherwise.</p>
<p>The 'max' attribute specifies the maximum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.</p> <p>The 'max' attribute specifies the maximum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.</p>
<p>The 'min' attribute specifies the minimum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.</p> <p>The 'min' attribute specifies the minimum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.</p>
@ -244,7 +244,7 @@
</xdv:validate> </xdv:validate>
</field> </field>
</x> </x>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Internationalization/Localization' anchor='impl-i18n'> <section2 topic='Internationalization/Localization' anchor='impl-i18n'>
<p>This document relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.</p> <p>This document relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.</p>
@ -352,7 +352,7 @@
<desc>a natural-language description of the datatype family</desc> <desc>a natural-language description of the datatype family</desc>
<doc>the document in which datatype family is specified</doc> <doc>the document in which datatype family is specified</doc>
</datatype-prefix> </datatype-prefix>
]]></code> ]]></code>
<p>The registrant may register more than one prefix at a time, each contained in a separate &lt;datatype-prefix/&gt; element.</p> <p>The registrant may register more than one prefix at a time, each contained in a separate &lt;datatype-prefix/&gt; element.</p>
</section4> </section4>
<section4 topic='Initial Submission' anchor='registrar-reg-prefixes-init'> <section4 topic='Initial Submission' anchor='registrar-reg-prefixes-init'>
@ -368,7 +368,7 @@
<desc>A "standard" datatype as defined in XML Schema Part 2</desc> <desc>A "standard" datatype as defined in XML Schema Part 2</desc>
<doc>XML Schema Part 2</doc> <doc>XML Schema Part 2</doc>
</datatype-prefix> </datatype-prefix>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
<section3 topic='Datatypes Registry' anchor='registar-reg-datatypes'> <section3 topic='Datatypes Registry' anchor='registar-reg-datatypes'>
@ -383,7 +383,7 @@
<min>the minimum value for the datatype (if any)</min> <min>the minimum value for the datatype (if any)</min>
<max>the maximum value for the datatype (if any)</max> <max>the maximum value for the datatype (if any)</max>
</datatype> </datatype>
]]></code> ]]></code>
<p>The registrant may register more than one datatype at a time, each contained in a separate &lt;datatype/&gt; element.</p> <p>The registrant may register more than one datatype at a time, each contained in a separate &lt;datatype/&gt; element.</p>
</section4> </section4>
<section4 topic='Initial Submission' anchor='registrar-reg-datatypes-init'> <section4 topic='Initial Submission' anchor='registrar-reg-datatypes-init'>
@ -480,7 +480,7 @@
<min>N/A</min> <min>N/A</min>
<max>N/A</max> <max>N/A</max>
</datatype> </datatype>
]]></code> ]]></code>
</section4> </section4>
</section3> </section3>
</section2> </section2>
@ -552,6 +552,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

8
xep-0123.xml
View File

@ -75,7 +75,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<p>The entity returns its associated items:</p> <p>The entity returns its associated items:</p>
<example caption='Entity Returns Disco Item Results'><![CDATA[ <example caption='Entity Returns Disco Item Results'><![CDATA[
<iq type='result' <iq type='result'
@ -90,7 +90,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Requesting Metadata About Another Entity'> <section2 topic='Requesting Metadata About Another Entity'>
<p>In order to request the advertised metadata, the requesting entity sends a disco#info request to the 'metadata' node of the JID communicated in the previous result.</p> <p>In order to request the advertised metadata, the requesting entity sends a disco#info request to the 'metadata' node of the JID communicated in the previous result.</p>
@ -102,7 +102,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='metadata'/> node='metadata'/>
</iq> </iq>
]]></example> ]]></example>
<p>The entity returns its metadata to the requestor.</p> <p>The entity returns its metadata to the requestor.</p>
<example caption='Entity Returns Metadata Result'><![CDATA[ <example caption='Entity Returns Metadata Result'><![CDATA[
<iq type='result' <iq type='result'
@ -120,7 +120,7 @@
</info> </info>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Integration with Directory Services'> <section1 topic='Integration with Directory Services'>

6
xep-0124.xml
View File

@ -214,7 +214,7 @@
| [HTTP + <body/> wrapper] | [HTTP + <body/> wrapper]
| |
Client Client
]]></code> ]]></code>
<p>This specification covers communication only between a client and the connection manager. It does not cover communication between the connection manager and the server, since such communications are implementation-specific (e.g., the server might natively support this HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity; alternatively the connection manager might be an independent translating proxy such that the server might believe it is talking directly to the client over TCP; or the connection manager and the server might use a component protocol or an API defined by the server implementation).</p> <p>This specification covers communication only between a client and the connection manager. It does not cover communication between the connection manager and the server, since such communications are implementation-specific (e.g., the server might natively support this HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity; alternatively the connection manager might be an independent translating proxy such that the server might believe it is talking directly to the client over TCP; or the connection manager and the server might use a component protocol or an API defined by the server implementation).</p>
<p>Furthermore, no aspect of this protocol limits its use to communication between a client and a server. For example, it could be used for communication between a server and a peer server if such communication can occur for the relevant application (e.g., in XMPP). However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use the native connection transport for the relevant application. (However, on some unreliable networks, BOSH might enable more stable communication between servers.)</p> <p>Furthermore, no aspect of this protocol limits its use to communication between a client and a server. For example, it could be used for communication between a server and a peer server if such communication can occur for the relevant application (e.g., in XMPP). However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use the native connection transport for the relevant application. (However, on some unreliable networks, BOSH might enable more stable communication between servers.)</p>
</section1> </section1>
@ -301,7 +301,7 @@ first socket second socket
| |*| | |*|
| +-+ | +-+
| | | |
]]></code> ]]></code>
</section1> </section1>
<section1 topic="HTTP Overview" anchor='overview'> <section1 topic="HTTP Overview" anchor='overview'>
<p>The requirements of <cite>RFC 2616</cite> MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by <cite>RFC 2616</cite> and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.</p> <p>The requirements of <cite>RFC 2616</cite> MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by <cite>RFC 2616</cite> and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.</p>
@ -1164,7 +1164,7 @@ Content-Length: 65
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>
<p>Thanks to Dave Cridland, Mike Cumings, Tomas Karasek, Steffen Larsen, Tobias Markmann, Matt Miller, Chris Seymour, Safa Sofuo&#287;lu, Stefan Strigler, Mike Taylor, Winfriend Tilanus, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback.</p> <p>Thanks to Dave Cridland, Mike Cumings, Tomas Karasek, Steffen Larsen, Tobias Markmann, Matt Miller, Chris Seymour, Safa Sofuo&#287;lu, Stefan Strigler, Mike Taylor, Winfriend Tilanus, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback.</p>

46
xep-0126.xml
View File

@ -99,14 +99,14 @@
<active name='invisible'/> <active name='invisible'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Naturally, the user could have defined this list during a previous session and could simply set the relevant list as active when logging in, rather than defining the list on login. Both steps are shown here for completeness.</p> <p>Naturally, the user could have defined this list during a previous session and could simply set the relevant list as active when logging in, rather than defining the list on login. Both steps are shown here for completeness.</p>
<p>The user may now send initial presence to the server.</p> <p>The user may now send initial presence to the server.</p>
<example caption='User Sends Initial Presence'><![CDATA[ <example caption='User Sends Initial Presence'><![CDATA[
<presence> <presence>
<status>I'm not really here, you understand!</status> <status>I'm not really here, you understand!</status>
</presence> </presence>
]]></example> ]]></example>
<p>Even though the user has sent initial presence, that presence information will not be broadcasted to any of the user's contacts, since the active privacy list blocks all outbound presence notifications.</p> <p>Even though the user has sent initial presence, that presence information will not be broadcasted to any of the user's contacts, since the active privacy list blocks all outbound presence notifications.</p>
</section2> </section2>
<section2 topic='Become Selectively Visible' anchor='vis-select'> <section2 topic='Become Selectively Visible' anchor='vis-select'>
@ -140,14 +140,14 @@
<active name='visible-to-Frodo'/> <active name='visible-to-Frodo'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list blocks outbound presence notifications to every JID except one.</p> <p>The foregoing privacy list blocks outbound presence notifications to every JID except one.</p>
<p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:</p> <p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm not really here, you understand!</status> <status>I'm not really here, you understand!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Becoming Visible by Roster Group' anchor='vis-select-roster'> <section3 topic='Becoming Visible by Roster Group' anchor='vis-select-roster'>
<example caption='User Defines and Sets Selective Visibility Privacy Rule (by Roster Group)'><![CDATA[ <example caption='User Defines and Sets Selective Visibility Privacy Rule (by Roster Group)'><![CDATA[
@ -172,13 +172,13 @@
<active name='visible-to-Bagginses'/> <active name='visible-to-Bagginses'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list blocks outbound presence notifications to every JID except those in a certain roster group. In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs in the specified roster group:</p> <p>The foregoing privacy list blocks outbound presence notifications to every JID except those in a certain roster group. In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs in the specified roster group:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm not really here, you understand!</status> <status>I'm not really here, you understand!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Becoming Visible by Subscription Type' anchor='vis-select-sub'> <section3 topic='Becoming Visible by Subscription Type' anchor='vis-select-sub'>
<p>Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.</p> <p>Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.</p>
@ -204,14 +204,14 @@
<active name='visible-to-both'/> <active name='visible-to-both'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list blocks outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "both".</p> <p>The foregoing privacy list blocks outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "both".</p>
<p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs with the specified subscription type:</p> <p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs with the specified subscription type:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm not really here, you understand!</status> <status>I'm not really here, you understand!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Become Globally Visible' anchor='vis-global'> <section2 topic='Become Globally Visible' anchor='vis-global'>
@ -232,7 +232,7 @@
<active name='visible'/> <active name='visible'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Because globally allowing outbound presence notifications is most likely the default behavior of any server, a more straightforward way to become globally visible is to decline the use of any active rule (the equivalent, as it were, of taking off a magic invisibility ring):</p> <p>Because globally allowing outbound presence notifications is most likely the default behavior of any server, a more straightforward way to become globally visible is to decline the use of any active rule (the equivalent, as it were, of taking off a magic invisibility ring):</p>
<example caption='User Declines the Use of Any Active Rule'><![CDATA[ <example caption='User Declines the Use of Any Active Rule'><![CDATA[
<iq from='bilbo@tolkien.lit/shire' type='set' id='active6'> <iq from='bilbo@tolkien.lit/shire' type='set' id='active6'>
@ -240,13 +240,13 @@
<active/> <active/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:</p> <p>In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm back!</status> <status>I'm back!</status>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Become Selectively Invisible' anchor='invis-select'> <section2 topic='Become Selectively Invisible' anchor='invis-select'>
<p>Let us now suppose that the user no longer wants to be globally visible, but desires to be invisible only to some -- but not all -- contacts. As with visibility, here again the 'jabber:iq:privacy' namespace gives the user three options:</p> <p>Let us now suppose that the user no longer wants to be globally visible, but desires to be invisible only to some -- but not all -- contacts. As with visibility, here again the 'jabber:iq:privacy' namespace gives the user three options:</p>
@ -267,7 +267,7 @@
<p>First, the user sends unavailable presence for broadcasting to all contacts:</p> <p>First, the user sends unavailable presence for broadcasting to all contacts:</p>
<example caption='User Sends Unavailable Presence'><![CDATA[ <example caption='User Sends Unavailable Presence'><![CDATA[
<presence type='unavailable'/> <presence type='unavailable'/>
]]></example> ]]></example>
<p>The server then broadcasts that presence to all of the user's contacts.</p> <p>The server then broadcasts that presence to all of the user's contacts.</p>
<p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p> <p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p>
<example caption='User Defines and Sets Selective Invisibility Privacy Rule (by JID)'><![CDATA[ <example caption='User Defines and Sets Selective Invisibility Privacy Rule (by JID)'><![CDATA[
@ -292,20 +292,20 @@
<active name='invisible-to-Gandalf'/> <active name='invisible-to-Gandalf'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list allows outbound presence notifications to every JID except one.</p> <p>The foregoing privacy list allows outbound presence notifications to every JID except one.</p>
<p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to the specified JID:</p> <p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to the specified JID:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm back!</status> <status>I'm back!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Becoming Invisible by Roster Group' anchor='invis-select-roster'> <section3 topic='Becoming Invisible by Roster Group' anchor='invis-select-roster'>
<p>First, the user sends unavailable presence for broadcasting to all contacts:</p> <p>First, the user sends unavailable presence for broadcasting to all contacts:</p>
<example caption='User Sends Unavailable Presence'><![CDATA[ <example caption='User Sends Unavailable Presence'><![CDATA[
<presence type='unavailable'/> <presence type='unavailable'/>
]]></example> ]]></example>
<p>The server then broadcasts that presence to all of the user's contacts.</p> <p>The server then broadcasts that presence to all of the user's contacts.</p>
<p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p> <p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p>
<example caption='User Defines and Sets Selective Invisibility Privacy Rule (by Roster Group)'><![CDATA[ <example caption='User Defines and Sets Selective Invisibility Privacy Rule (by Roster Group)'><![CDATA[
@ -330,21 +330,21 @@
<active name='invisible-to-Wizards'/> <active name='invisible-to-Wizards'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list allows outbound presence notifications to every JID except those in a certain roster group.</p> <p>The foregoing privacy list allows outbound presence notifications to every JID except those in a certain roster group.</p>
<p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those in the specified roster group:</p> <p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those in the specified roster group:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm back!</status> <status>I'm back!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Becoming Invisible by Subscription Type' anchor='invis-select-sub'> <section3 topic='Becoming Invisible by Subscription Type' anchor='invis-select-sub'>
<p>Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.</p> <p>Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.</p>
<p>First, the user sends unavailable presence for broadcasting to all contacts:</p> <p>First, the user sends unavailable presence for broadcasting to all contacts:</p>
<example caption='User Sends Unavailable Presence'><![CDATA[ <example caption='User Sends Unavailable Presence'><![CDATA[
<presence type='unavailable'/> <presence type='unavailable'/>
]]></example> ]]></example>
<p>The server then broadcasts that presence to all of the user's contacts.</p> <p>The server then broadcasts that presence to all of the user's contacts.</p>
<p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p> <p>Second, the user defines and sets a privacy rule that allows selective invisibility:</p>
<example caption='User Defines and Sets Selective Invisibility Privacy Rule (by Subscription State)'><![CDATA[ <example caption='User Defines and Sets Selective Invisibility Privacy Rule (by Subscription State)'><![CDATA[
@ -369,14 +369,14 @@
<active name='invisible-to-from'/> <active name='invisible-to-from'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing privacy list allows outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "to".</p> <p>The foregoing privacy list allows outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "to".</p>
<p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those with the specified subscription type:</p> <p>In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those with the specified subscription type:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm back!</status> <status>I'm back!</status>
</presence> </presence>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Become Globally Invisible' anchor='invis-global'> <section2 topic='Become Globally Invisible' anchor='invis-global'>
@ -384,7 +384,7 @@
<p>First, the user sends unavailable presence for broadcasting to all contacts:</p> <p>First, the user sends unavailable presence for broadcasting to all contacts:</p>
<example caption='User Sends Unavailable Presence'><![CDATA[ <example caption='User Sends Unavailable Presence'><![CDATA[
<presence type='unavailable'/> <presence type='unavailable'/>
]]></example> ]]></example>
<p>Second, the user sets as active the global invisibility list previously defined:</p> <p>Second, the user sets as active the global invisibility list previously defined:</p>
<example caption='User Becomes Globally Invisible'><![CDATA[ <example caption='User Becomes Globally Invisible'><![CDATA[
<iq from='bilbo@tolkien.lit/shire' type='set' id='active10'> <iq from='bilbo@tolkien.lit/shire' type='set' id='active10'>
@ -392,13 +392,13 @@
<active name='invisible'/> <active name='invisible'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In order to appear globally invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all contacts:</p> <p>In order to appear globally invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all contacts:</p>
<example caption='Client Sends Available Presence'><![CDATA[ <example caption='Client Sends Available Presence'><![CDATA[
<presence> <presence>
<status>I'm not really here, you understand!</status> <status>I'm not really here, you understand!</status>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>

6
xep-0127.xml
View File

@ -109,7 +109,7 @@
</info> </info>
</alert> </alert>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='PubSub'> <section2 topic='PubSub'>
<p>The publish-subscribe protocol defined in XEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.</p> <p>The publish-subscribe protocol defined in XEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.</p>
@ -168,7 +168,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>If the pubsub node is configured to deliver payloads, the information is then sent to all subscribers.</p> <p>If the pubsub node is configured to deliver payloads, the information is then sent to all subscribers.</p>
<example caption='An Alert Sent as a PubSub Payload'><![CDATA[ <example caption='An Alert Sent as a PubSub Payload'><![CDATA[
<message from='pubsub.jabber.org' <message from='pubsub.jabber.org'
@ -223,7 +223,7 @@
. .
. .
. .
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations'> <section1 topic='Security Considerations'>

4
xep-0128.xml
View File

@ -110,7 +110,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Multi-User Chat Room' anchor='examples-muc'> <section2 topic='Multi-User Chat Room' anchor='examples-muc'>
<p>The following is an example of including a disco extension in the IQ result sent by a Multi-User Chat room.</p> <p>The following is an example of including a disco extension in the IQ result sent by a Multi-User Chat room.</p>
@ -152,7 +152,7 @@
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>

22
xep-0129.xml
View File

@ -69,12 +69,12 @@
Content-Type: text/html Content-Type: text/html
[body omitted] [body omitted]
]]></example> ]]></example>
<p>Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to perform operations such as DELETE, MOVE, and PROPPATCH.</p> <p>Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to perform operations such as DELETE, MOVE, and PROPPATCH.</p>
<example caption='HTTP OK'><![CDATA[ <example caption='HTTP OK'><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 15:01:20 GMT Date: Thu, 18 Dec 2003 15:01:20 GMT
]]></example> ]]></example>
<p>In the absence of any other authorization method (e.g., &rfc3744; or &saml;) in use by the deployed WebDAV server, the client SHOULD perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.</p> <p>In the absence of any other authorization method (e.g., &rfc3744; or &saml;) in use by the deployed WebDAV server, the client SHOULD perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.</p>
<example caption='PROPPATCH Request'><![CDATA[ <example caption='PROPPATCH Request'><![CDATA[
PROPPATCH /missive.html HTTP/1.1 PROPPATCH /missive.html HTTP/1.1
@ -94,7 +94,7 @@
</prop> </prop>
</set> </set>
</propertyupdate> </propertyupdate>
]]></example> ]]></example>
<p>Note: The semantics of the JID list defined above are:</p> <p>Note: The semantics of the JID list defined above are:</p>
<ul> <ul>
<li>If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).</li> <li>If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).</li>
@ -117,7 +117,7 @@
</propstat> </propstat>
</response> </response>
</multistatus> </multistatus>
]]></example> ]]></example>
<p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encapsulated via &xep0066;. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p> <p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encapsulated via &xep0066;. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<example caption='Sender Generates XMPP Message with URL'><![CDATA[ <example caption='Sender Generates XMPP Message with URL'><![CDATA[
<message from='romeo@montague.net/pda' to='multicast.jabber.org'> <message from='romeo@montague.net/pda' to='multicast.jabber.org'>
@ -130,7 +130,7 @@
<url>http://files.shakespeare.lit/missive.html</url> <url>http://files.shakespeare.lit/missive.html</url>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).</p> <p>When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).</p>
<example caption='Recipient GET Request'><![CDATA[ <example caption='Recipient GET Request'><![CDATA[
GET /missive.html HTTP/1.1 GET /missive.html HTTP/1.1
@ -144,7 +144,7 @@
cnonce="0a4f113b", cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example> ]]></example>
<p>The server then checks to ensure that the provided JID was specified via the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p> <p>The server then checks to ensure that the provided JID was specified via the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p>
<example caption='Confirmation Request Sent via Message'><![CDATA[ <example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal' <message type='normal'
@ -156,7 +156,7 @@
method='GET' method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/> url='https://files.shakespeare.lit:9345/missive.html'/>
</message> </message>
]]></example> ]]></example>
<p>If the <cite>XEP-0070</cite> verification is successful, the server then allows the file to be retrieved:</p> <p>If the <cite>XEP-0070</cite> verification is successful, the server then allows the file to be retrieved:</p>
<example caption='Server Returns File'><![CDATA[ <example caption='Server Returns File'><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
@ -165,7 +165,7 @@
Content-Length: xxx Content-Length: xxx
[body omitted] [body omitted]
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" &NSNOTE;. An example of the discovery flow is shown below.</p> <p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" &NSNOTE;. An example of the discovery flow is shown below.</p>
@ -187,7 +187,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client Queries Service Regarding Supported Features'><![CDATA[ <example caption='Client Queries Service Regarding Supported Features'><![CDATA[
<iq from='romeo@shakespeare.lit/home' <iq from='romeo@shakespeare.lit/home'
id='disco2' id='disco2'
@ -207,7 +207,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The user now knows that the "files.shakespeare.lit" service supports this protocol.</p> <p>The user now knows that the "files.shakespeare.lit" service supports this protocol.</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
@ -240,7 +240,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Lisa Dusseault and Julian Reschke for their feedback.</p> <p>Thanks to Lisa Dusseault and Julian Reschke for their feedback.</p>

76
xep-0130.xml
View File

@ -405,7 +405,7 @@
<iq type='get' id='agent1'> <iq type='get' id='agent1'>
<query xmlns='jabber:iq:agents'/> <query xmlns='jabber:iq:agents'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Server Returns Address of its WaitingListService"><![CDATA[ <example caption="Server Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='agent1'> <iq type='result' id='agent1'>
<query xmlns='jabber:iq:agents'> <query xmlns='jabber:iq:agents'>
@ -417,12 +417,12 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="IM User Discovers WaitingListService by Sending Service Discovery Request to its Server"><![CDATA[ <example caption="IM User Discovers WaitingListService by Sending Service Discovery Request to its Server"><![CDATA[
<iq type='get' id='disco1'> <iq type='get' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Server Returns Address of its WaitingListService"><![CDATA[ <example caption="Server Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='disco1'> <iq type='result' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'> <query xmlns='http://jabber.org/protocol/disco#items'>
@ -432,7 +432,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="IM User Queries WaitingListService for Detailed Information"><![CDATA[ <example caption="IM User Queries WaitingListService for Detailed Information"><![CDATA[
<iq type='get' <iq type='get'
from='user@service-provider.com/resource' from='user@service-provider.com/resource'
@ -440,7 +440,7 @@
id='disco2'> id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The WaitingListService SHOULD return detailed information about the service it provides, including the URI schemes it supports (see also the <link url='#registrar-features'>Service Discovery Features</link> section of this document).</p> <p>The WaitingListService SHOULD return detailed information about the service it provides, including the URI schemes it supports (see also the <link url='#registrar-features'>Service Discovery Features</link> section of this document).</p>
<example caption="WaitingListService Returns Detailed Information"><![CDATA[ <example caption="WaitingListService Returns Detailed Information"><![CDATA[
<iq type='result' <iq type='result'
@ -454,7 +454,7 @@
<feature var='http://jabber.org/protocol/waitinglist/schemes/tel'/> <feature var='http://jabber.org/protocol/waitinglist/schemes/tel'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Once an IM User has discovered the WaitingListService, the user's client SHOULD request its current Waiting List. This is done by sending an IQ-get to the WaitingListService containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:</p> <p>Once an IM User has discovered the WaitingListService, the user's client SHOULD request its current Waiting List. This is done by sending an IQ-get to the WaitingListService containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:</p>
<example caption="IM User Requests its Current WaitingList"><![CDATA[ <example caption="IM User Requests its Current WaitingList"><![CDATA[
<iq type='get' <iq type='get'
@ -463,7 +463,7 @@
id='request1'> id='request1'>
<query xmlns='http://jabber.org/protocol/waitinglist'/> <query xmlns='http://jabber.org/protocol/waitinglist'/>
</iq> </iq>
]]></example> ]]></example>
<p>Upon request, the WaitingListService MUST return the current WaitingList to the IM User:</p> <p>Upon request, the WaitingListService MUST return the current WaitingList to the IM User:</p>
<example caption="WaitingListService Returns WaitingList to IM User"><![CDATA[ <example caption="WaitingListService Returns WaitingList to IM User"><![CDATA[
<iq type='result' <iq type='result'
@ -481,7 +481,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Each ItemID MUST be unique within the scope of the client's WaitingList items. The value of the ItemID is an opaque string; an implementation MAY assign semantic meaning to the ItemID (e.g., id="John Smith (mobile)" rather than id="12345"), but such meaning is implementation-specific and outside the scope of the protocol defined herein. The user MAY include a &lt;name/&gt; element containing a natural-language name for the Contact.</p> <p>Each ItemID MUST be unique within the scope of the client's WaitingList items. The value of the ItemID is an opaque string; an implementation MAY assign semantic meaning to the ItemID (e.g., id="John Smith (mobile)" rather than id="12345"), but such meaning is implementation-specific and outside the scope of the protocol defined herein. The user MAY include a &lt;name/&gt; element containing a natural-language name for the Contact.</p>
<p>The WaitingList MAY contain an item for which a JID has been discovered.</p> <p>The WaitingList MAY contain an item for which a JID has been discovered.</p>
<example caption="IM User Asks for its WaitingList including Newly Discovered JID"><![CDATA[ <example caption="IM User Asks for its WaitingList including Newly Discovered JID"><![CDATA[
@ -507,7 +507,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="IM User Adds Contact to WaitingList" anchor='protocol-imuser-add'> <section3 topic="IM User Adds Contact to WaitingList" anchor='protocol-imuser-add'>
<p>Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This document uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)</p> <p>Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This document uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)</p>
@ -522,7 +522,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>As described below, various error conditions may occur. (For information about error syntax, refer to <cite>RFC 6120</cite> and &xep0086;.)</p> <p>As described below, various error conditions may occur. (For information about error syntax, refer to <cite>RFC 6120</cite> and &xep0086;.)</p>
<p>If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.</p> <p>If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.</p>
<example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[
@ -540,7 +540,7 @@
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the IM User included a JID in the request, WaitingListService MUST return a &badrequest; error to IM User and MUST NOT add the Contact to the WaitingList. (Note: A WaitingListService MUST NOT return a non-XMPP URI to an IM User based on the Contact's JID; see the <link url='#security'>Security Considerations</link> section of this document.)</p> <p>If the IM User included a JID in the request, WaitingListService MUST return a &badrequest; error to IM User and MUST NOT add the Contact to the WaitingList. (Note: A WaitingListService MUST NOT return a non-XMPP URI to an IM User based on the Contact's JID; see the <link url='#security'>Security Considerations</link> section of this document.)</p>
<example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[
<iq type='error' <iq type='error'
@ -557,7 +557,7 @@
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the IM User provided an invalid URI (e.g., a phone number with too many digits or an email address with no '@' character), WaitingListService MUST return a &notacceptable; error to the IM User and MUST NOT add the Contact to the WaitingList.</p> <p>If the IM User provided an invalid URI (e.g., a phone number with too many digits or an email address with no '@' character), WaitingListService MUST return a &notacceptable; error to the IM User and MUST NOT add the Contact to the WaitingList.</p>
<example caption='WaitingListService Returns &notacceptable; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &notacceptable; Error to IM User'><![CDATA[
<iq type='error' <iq type='error'
@ -574,7 +574,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If one of the foregoing errors was generated (all of which have a type of "modify"), IM User SHOULD modify the request and re-submit it.</p> <p>If one of the foregoing errors was generated (all of which have a type of "modify"), IM User SHOULD modify the request and re-submit it.</p>
<p>If none of the "modify" errors was generated, WaitingListService MUST inform the IM User that the request was successfully received, including a unique ID number for the new WaitingList item.</p> <p>If none of the "modify" errors was generated, WaitingListService MUST inform the IM User that the request was successfully received, including a unique ID number for the new WaitingList item.</p>
<example caption="WaitingListService Informs IM User that Request was Received"><![CDATA[ <example caption="WaitingListService Informs IM User that Request was Received"><![CDATA[
@ -586,7 +586,7 @@
<item id='34567'/> <item id='34567'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If none of the "modify" errors was generated and WaitingListService knows Contact JID when the IQ result is returned to the user (e.g., because Contact is served by ServiceProvider), WaitingListService MAY include the WaitingList item in the IQ result: <note>Even if WaitingListService returns Contact JID in the IQ-result, it MUST also send a "JID push" message.</note></p> <p>If none of the "modify" errors was generated and WaitingListService knows Contact JID when the IQ result is returned to the user (e.g., because Contact is served by ServiceProvider), WaitingListService MAY include the WaitingList item in the IQ result: <note>Even if WaitingListService returns Contact JID in the IQ-result, it MUST also send a "JID push" message.</note></p>
<example caption="WaitingListService Returns IQ Result to IM User (With Contact JID)"><![CDATA[ <example caption="WaitingListService Returns IQ Result to IM User (With Contact JID)"><![CDATA[
<iq type='result' <iq type='result'
@ -600,7 +600,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If none of the "modify" errors was generated and WaitingListService does not know Contact JID when the IQ result is returned to the user, it needs to contact InteropPartners in order to determine if the Contact is associated with one of the InteropPartners. Thus before it returns the Contact JID to the IM User, it needs to wait for the one of the InteropPartners to return Contact JID or for all of the InteropPartners to return errors.</p> <p>If none of the "modify" errors was generated and WaitingListService does not know Contact JID when the IQ result is returned to the user, it needs to contact InteropPartners in order to determine if the Contact is associated with one of the InteropPartners. Thus before it returns the Contact JID to the IM User, it needs to wait for the one of the InteropPartners to return Contact JID or for all of the InteropPartners to return errors.</p>
<p>If all of the InteropPartners return an error of type "cancel" (typically &notfound; and/or &notauthorized;) to WaitingListService, WaitingListService MUST return an &notfound; error (or local equivalent) to the IM User (and IM User SHOULD complete <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case).</p> <p>If all of the InteropPartners return an error of type "cancel" (typically &notfound; and/or &notauthorized;) to WaitingListService, WaitingListService MUST return an &notfound; error (or local equivalent) to the IM User (and IM User SHOULD complete <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case).</p>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
@ -619,7 +619,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
]]></example> ]]></example>
<p>If the connection to at least one of the InteropPartners times out (a &timeout; error), WaitingListService MUST return an IQ-result as described above (indicating that the request was received) and resend the request to the InteropPartners that timed out. If connections continue to time out (over some configurable time period and for some configurable number of retries), WaitingListService SHOULD then return a &timeout; error to IM User via a "JID push" message as shown below.</p> <p>If the connection to at least one of the InteropPartners times out (a &timeout; error), WaitingListService MUST return an IQ-result as described above (indicating that the request was received) and resend the request to the InteropPartners that timed out. If connections continue to time out (over some configurable time period and for some configurable number of retries), WaitingListService SHOULD then return a &timeout; error to IM User via a "JID push" message as shown below.</p>
<p>If InterPartner's WaitingListService knows the Contact JID, it sends it to ServiceProvider's WaitingListService as shown in the <link url='#protocol-service-add'>ServiceProvider's WaitingListService Adds Contact to WaitingList</link> section of this document.</p> <p>If InterPartner's WaitingListService knows the Contact JID, it sends it to ServiceProvider's WaitingListService as shown in the <link url='#protocol-service-add'>ServiceProvider's WaitingListService Adds Contact to WaitingList</link> section of this document.</p>
<p>If WaitingListService knows Contact JID (or learns Contact JID from InteropPartner), it MUST inform IM User through a "JID push" message, which consists of a message stanza that contains a &lt;waitlist/&gt; element qualified by the 'http://jabber.org/protocol/waitinglist' namespace: <p>If WaitingListService knows Contact JID (or learns Contact JID from InteropPartner), it MUST inform IM User through a "JID push" message, which consists of a message stanza that contains a &lt;waitlist/&gt; element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:
@ -637,7 +637,7 @@
</item> </item>
</waitlist> </waitlist>
</message> </message>
]]></example> ]]></example>
<p>Note: The JID push uses an XMPP &lt;message/&gt; stanza because the WaitingListService has no knowledge of the user's presence and therefore cannot assume that an &IQ; stanza will be received by the user at a specific resource.</p> <p>Note: The JID push uses an XMPP &lt;message/&gt; stanza because the WaitingListService has no knowledge of the user's presence and therefore cannot assume that an &IQ; stanza will be received by the user at a specific resource.</p>
<p>If WaitingListService learns that Contact's URI is not handled by any InteropPartner, it MUST inform IM User through a "JID push" message:</p> <p>If WaitingListService learns that Contact's URI is not handled by any InteropPartner, it MUST inform IM User through a "JID push" message:</p>
<example caption="WaitingListService Informs IM User that No InteropPartner Handles Contact's URI"><![CDATA[ <example caption="WaitingListService Informs IM User that No InteropPartner Handles Contact's URI"><![CDATA[
@ -659,7 +659,7 @@
</item> </item>
</waitlist> </waitlist>
</message> </message>
]]></example> ]]></example>
<p>After receiving the "JID push" message, IM User SHOULD complete the <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</p> <p>After receiving the "JID push" message, IM User SHOULD complete the <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</p>
</section3> </section3>
<section3 topic="IM User Removes Contact from WaitingList" anchor='protocol-imuser-remove'> <section3 topic="IM User Removes Contact from WaitingList" anchor='protocol-imuser-remove'>
@ -675,14 +675,14 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If WaitingListService previously recorded request, WaitingListService removes request from list and returns result to IM User.</p> <p>If WaitingListService previously recorded request, WaitingListService removes request from list and returns result to IM User.</p>
<example caption="WaitingListService Returns Result to IM User"><![CDATA[ <example caption="WaitingListService Returns Result to IM User"><![CDATA[
<iq type='result' <iq type='result'
from='waitlist.service-provider.com' from='waitlist.service-provider.com'
to='user@service-provider.com/resource' to='user@service-provider.com/resource'
id='remove1'/> id='remove1'/>
]]></example> ]]></example>
<p>If WaitingListService did not previously record this request, WaitingListService MUST return an &notfound; error to the IM User.</p> <p>If WaitingListService did not previously record this request, WaitingListService MUST return an &notfound; error to the IM User.</p>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
<iq type='error' id='remove1'> <iq type='error' id='remove1'>
@ -695,7 +695,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic="WaitingListService Interaction With InteropPartners" anchor='protocol-service'> <section2 topic="WaitingListService Interaction With InteropPartners" anchor='protocol-service'>
@ -712,7 +712,7 @@
id='agent2'> id='agent2'>
<query xmlns='jabber:iq:agents'/> <query xmlns='jabber:iq:agents'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[ <example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[
<iq type='result' <iq type='result'
from='interop-partner.com' from='interop-partner.com'
@ -727,7 +727,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Service Discovery Request to InteropPartner"><![CDATA[ <example caption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Service Discovery Request to InteropPartner"><![CDATA[
<iq type='get' <iq type='get'
from='waitlist.service-provider.com' from='waitlist.service-provider.com'
@ -735,7 +735,7 @@
id='disco3'> id='disco3'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[ <example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='disco3'> <iq type='result' id='disco3'>
<query xmlns='http://jabber.org/protocol/disco#items'> <query xmlns='http://jabber.org/protocol/disco#items'>
@ -745,7 +745,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Provider Queries InteropPartner's WaitingListService for Detailed Information"><![CDATA[ <example caption="Service Provider Queries InteropPartner's WaitingListService for Detailed Information"><![CDATA[
<iq type='get' <iq type='get'
from='waitlist.service-provider.com' from='waitlist.service-provider.com'
@ -753,7 +753,7 @@
id='disco4'> id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="InteropPartner's WaitingListService Returns Detailed Information"><![CDATA[ <example caption="InteropPartner's WaitingListService Returns Detailed Information"><![CDATA[
<iq type='result' <iq type='result'
from='waitlist.interop-partner.com' from='waitlist.interop-partner.com'
@ -765,7 +765,7 @@
<feature var='http://jabber.org/protocol/waitinglist'/> <feature var='http://jabber.org/protocol/waitinglist'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="ServiceProvider's WaitingListService Adds Contact to WaitingList" anchor='protocol-service-add'> <section3 topic="ServiceProvider's WaitingListService Adds Contact to WaitingList" anchor='protocol-service-add'>
<p>Once a ServiceProvider's WaitingListService has discovered the InteropPartner's WaitingListService and requested its WaitingList, the ServiceProvider's WaitingListService can add items to its WaitingList based on URI.</p> <p>Once a ServiceProvider's WaitingListService has discovered the InteropPartner's WaitingListService and requested its WaitingList, the ServiceProvider's WaitingListService can add items to its WaitingList based on URI.</p>
@ -780,7 +780,7 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If InteropPartner refuses to provide service to ServiceProvider, it MUST return a &notauthorized; error to the ServiceProvider:</p> <p>If InteropPartner refuses to provide service to ServiceProvider, it MUST return a &notauthorized; error to the ServiceProvider:</p>
<example caption='InteropPartner Returns &notauthorized; Error to ServiceProvider'><![CDATA[ <example caption='InteropPartner Returns &notauthorized; Error to ServiceProvider'><![CDATA[
<iq type='error' <iq type='error'
@ -796,7 +796,7 @@
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If Contact's URI is not associated with a person served by this InteropPartner, the InteropPartner MUST return an &notfound; error to the ServiceProvider.</p> <p>If Contact's URI is not associated with a person served by this InteropPartner, the InteropPartner MUST return an &notfound; error to the ServiceProvider.</p>
<example caption='InteropPartner Returns &notfound; Error to ServiceProvider'><![CDATA[ <example caption='InteropPartner Returns &notfound; Error to ServiceProvider'><![CDATA[
<iq type='error' <iq type='error'
@ -812,7 +812,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If ServiceProvider's WaitingListService receives &notauthorized; and/or &notfound; errors from all InteropPartners, it returns a &notfound; error to IM User:</p> <p>If ServiceProvider's WaitingListService receives &notauthorized; and/or &notfound; errors from all InteropPartners, it returns a &notfound; error to IM User:</p>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[ <example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
<message <message
@ -830,7 +830,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
]]></example> ]]></example>
<p>If Contact's URI is associated with a person served by this InteropPartner, InteropPartner MUST return acknowledgement of the WaitingList addition to the ServiceProvider's WaitingListService.</p> <p>If Contact's URI is associated with a person served by this InteropPartner, InteropPartner MUST return acknowledgement of the WaitingList addition to the ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner's WaitingListService Acknowledges Receipt"><![CDATA[ <example caption="InteropPartner's WaitingListService Acknowledges Receipt"><![CDATA[
<iq type='result' <iq type='result'
@ -841,7 +841,7 @@
<item id='34567'/> <item id='34567'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If Contact is an IM User served by InteropPartner, InteropPartner's WaitingListService pushes Contact's JID to ServiceProvider's WaitingListService.</p> <p>If Contact is an IM User served by InteropPartner, InteropPartner's WaitingListService pushes Contact's JID to ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner's WaitingListService Pushes Contact's JID to ServiceProvider's WaitingListService"><![CDATA[ <example caption="InteropPartner's WaitingListService Pushes Contact's JID to ServiceProvider's WaitingListService"><![CDATA[
<iq type='set' <iq type='set'
@ -854,13 +854,13 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption="ServiceProvider's WaitingListService Acknowledges Receipt of JID Push"><![CDATA[ <example caption="ServiceProvider's WaitingListService Acknowledges Receipt of JID Push"><![CDATA[
<iq type='result' <iq type='result'
from='waitlist.service-provider.com' from='waitlist.service-provider.com'
to='waitlist.interop-partner.com' to='waitlist.interop-partner.com'
id='jidpush1'/> id='jidpush1'/>
]]></example> ]]></example>
<p>After receiving acknowledgement (but not before), InteropPartner's WaitingListService MUST remove that item from the WaitingList for the ServiceProvider's WaitingListService.</p> <p>After receiving acknowledgement (but not before), InteropPartner's WaitingListService MUST remove that item from the WaitingList for the ServiceProvider's WaitingListService.</p>
</section3> </section3>
<section3 topic="ServiceProvider's WaitingListService Removes Contact from WaitingList" anchor='protocol-service-remove'> <section3 topic="ServiceProvider's WaitingListService Removes Contact from WaitingList" anchor='protocol-service-remove'>
@ -875,14 +875,14 @@
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If item exists on WaitingList, InteropPartner's WaitingListService removes item from list and returns result to ServiceProvider's WaitingListService.</p> <p>If item exists on WaitingList, InteropPartner's WaitingListService removes item from list and returns result to ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner Returns Result to ServiceProvider"><![CDATA[ <example caption="InteropPartner Returns Result to ServiceProvider"><![CDATA[
<iq type='result' <iq type='result'
from='waitlist.interop-partner.com' from='waitlist.interop-partner.com'
to='waitlist.service-provider.com' to='waitlist.service-provider.com'
id='remove2'/> id='remove2'/>
]]></example> ]]></example>
<p>If item does not exist on WaitingList, InteropPartner's WaitingListService MUST return an &notfound; error to the ServiceProvider's WaitingListService.</p> <p>If item does not exist on WaitingList, InteropPartner's WaitingListService MUST return an &notfound; error to the ServiceProvider's WaitingListService.</p>
<example caption='InteropPartner Returns &notfound; Error to ServiceProvider'><![CDATA[ <example caption='InteropPartner Returns &notfound; Error to ServiceProvider'><![CDATA[
<iq type='error' <iq type='error'
@ -898,7 +898,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -1048,6 +1048,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

24
xep-0131.xml
View File

@ -112,7 +112,7 @@
to='juliet@capulet.com/balcony'> to='juliet@capulet.com/balcony'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Queried entity communicates protocol support'><![CDATA[ <example caption='Queried entity communicates protocol support'><![CDATA[
<iq from='romeo@montague.net/orchard' <iq from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'> to='juliet@capulet.com/balcony'>
@ -122,7 +122,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Header Support' anchor='disco-header'> <section2 topic='Header Support' anchor='disco-header'>
<p>It can be desirable (and, in some contexts, necessary) to determine if the intended recipient of an XML stanza supports a specific header (e.g., the "Classification" header) before sending information that may depend on that header. Therefore, implementations of this protocol MUST advertise which particular SHIM headers they support when queried via disco#info at the well-known service discovery node 'http://jabber.org/protocol/shim'.</p> <p>It can be desirable (and, in some contexts, necessary) to determine if the intended recipient of an XML stanza supports a specific header (e.g., the "Classification" header) before sending information that may depend on that header. Therefore, implementations of this protocol MUST advertise which particular SHIM headers they support when queried via disco#info at the well-known service discovery node 'http://jabber.org/protocol/shim'.</p>
@ -132,7 +132,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim'/> node='http://jabber.org/protocol/shim'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Queried entity communicates header support'><![CDATA[ <example caption='Queried entity communicates header support'><![CDATA[
<iq from='romeo@montague.net/orchard' <iq from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'> to='juliet@capulet.com/balcony'>
@ -145,7 +145,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The values of the 'var' attribute MUST be of the form "http://jabber.org/protocol/shim#header", where "header" is to be replaced with the name of the header as registered with the &REGISTRAR; (see below).</p> <p>The values of the 'var' attribute MUST be of the form "http://jabber.org/protocol/shim#header", where "header" is to be replaced with the name of the header as registered with the &REGISTRAR; (see below).</p>
</section2> </section2>
</section1> </section1>
@ -162,7 +162,7 @@
<header name='Keywords'>shakespeare,&lt;xmpp/&gt;</header> <header name='Keywords'>shakespeare,&lt;xmpp/&gt;</header>
</headers> </headers>
</message> </message>
]]></example> ]]></example>
<p>In accordance with &xmppcore;, an &IQ; stanza must not contain more than one non-error child element; this places constraints on the location of SHIM headers in the XML hierarchy. Specifically, the &lt;headers/&gt; wrapper element MUST NOT be a direct child of &IQ; and instead SHOULD be a grandchild of &IQ; and a direct child of the content-bearing child element of &IQ; (e.g., &QUERY;, <em>not</em> &lt;error/&gt;).</p> <p>In accordance with &xmppcore;, an &IQ; stanza must not contain more than one non-error child element; this places constraints on the location of SHIM headers in the XML hierarchy. Specifically, the &lt;headers/&gt; wrapper element MUST NOT be a direct child of &IQ; and instead SHOULD be a grandchild of &IQ; and a direct child of the content-bearing child element of &IQ; (e.g., &QUERY;, <em>not</em> &lt;error/&gt;).</p>
<example caption='An IQ example'><![CDATA[ <example caption='An IQ example'><![CDATA[
<iq from='romeo@montague.net/orchard' <iq from='romeo@montague.net/orchard'
@ -174,7 +174,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Header Definitions' anchor='headers'> <section1 topic='Header Definitions' anchor='headers'>
<p>All public headers SHOULD be registered with the XMPP Registrar following the process specified in the <link url="#registrar">XMPP Registrar Considerations</link> section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.</p> <p>All public headers SHOULD be registered with the XMPP Registrar following the process specified in the <link url="#registrar">XMPP Registrar Considerations</link> section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.</p>
@ -203,7 +203,7 @@
<header name='TTL'>3600</header> <header name='TTL'>3600</header>
</headers> </headers>
</presence> </presence>
]]></example> ]]></example>
<p>Another potential application is specifying a time to live for <cite>Service Discovery</cite> results, which helps other entities know how long to cache such information:</p> <p>Another potential application is specifying a time to live for <cite>Service Discovery</cite> results, which helps other entities know how long to cache such information:</p>
<example caption='Time to Live for Disco Information'><![CDATA[ <example caption='Time to Live for Disco Information'><![CDATA[
<iq from='example.com' <iq from='example.com'
@ -220,7 +220,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Urgency' anchor='headers-urgency'> <section2 topic='Urgency' anchor='headers-urgency'>
<p>It can be useful to specify that the information contained in a stanza is more or less time-sensitive (e.g., in order to help the recipient determine whether to attend to the information immediately or to delay attending to the information). Such is the function of the "Urgency" header, the value of which is "high", "medium", or "low". One use of the header is Sieve notifications (see &sievenotify;) sent via XMPP, as specified in &sievenotifyxmpp;.</p> <p>It can be useful to specify that the information contained in a stanza is more or less time-sensitive (e.g., in order to help the recipient determine whether to attend to the information immediately or to delay attending to the information). Such is the function of the "Urgency" header, the value of which is "high", "medium", or "low". One use of the header is Sieve notifications (see &sievenotify;) sent via XMPP, as specified in &sievenotifyxmpp;.</p>
@ -234,7 +234,7 @@
<header name='Urgency'>high</header> <header name='Urgency'>high</header>
</headers> </headers>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='A Note About Date-Related Headers' anchor='dates'> <section1 topic='A Note About Date-Related Headers' anchor='dates'>
@ -265,7 +265,7 @@
<desc>a natural-language description of the header</desc> <desc>a natural-language description of the header</desc>
<doc>the document in which this header is specified</doc> <doc>the document in which this header is specified</doc>
</header> </header>
]]></code> ]]></code>
<p>The registrant may register more than one header at a time, each contained in a separate &lt;header/&gt; element.</p> <p>The registrant may register more than one header at a time, each contained in a separate &lt;header/&gt; element.</p>
</section3> </section3>
<section3 topic='Initial Registration' anchor='registrar-shim-init'> <section3 topic='Initial Registration' anchor='registrar-shim-init'>
@ -894,7 +894,7 @@
<doc>RFC 2616</doc> <doc>RFC 2616</doc>
</header> </header>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -934,6 +934,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

20
xep-0132.xml
View File

@ -50,7 +50,7 @@
id='poke1'> id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/> <poke xmlns='http://jabber.org/protocol/poke'/>
</presence> </presence>
]]></example> ]]></example>
<p>If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &xep0086;):</p> <p>If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &xep0086;):</p>
<example caption='Server returns service unavailable error'><![CDATA[ <example caption='Server returns service unavailable error'><![CDATA[
<presence <presence
@ -64,7 +64,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
<p>If the user's server supports the POKE protocol, it MUST first perform appropriate access checks to determine if the requesting entity has permission to view the user's presence (e.g., by checking presence subscriptions and privacy lists). If the user's server determines that the requesting entity is not allowed to learn the user's physical presence information, it MUST return a "Forbidden" error:</p> <p>If the user's server supports the POKE protocol, it MUST first perform appropriate access checks to determine if the requesting entity has permission to view the user's presence (e.g., by checking presence subscriptions and privacy lists). If the user's server determines that the requesting entity is not allowed to learn the user's physical presence information, it MUST return a "Forbidden" error:</p>
<example caption='Server returns forbidden error'><![CDATA[ <example caption='Server returns forbidden error'><![CDATA[
<presence <presence
@ -78,7 +78,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
<p>If the requesting entity has permission to discover the user's physical presence, the server SHOULD attempt to determine if the user is physically present. Methods for doing so are implementation-specific and therefore out of scope for this document, but possible mechanisms might include:</p> <p>If the requesting entity has permission to discover the user's physical presence, the server SHOULD attempt to determine if the user is physically present. Methods for doing so are implementation-specific and therefore out of scope for this document, but possible mechanisms might include:</p>
<ol> <ol>
<li>sending messages to contacts in the user's roster who would be likely to have knowledge of the user's whereabouts (perhaps derived from physical proximity information gleaned from &xep0054; or &xep0080; data)</li> <li>sending messages to contacts in the user's roster who would be likely to have knowledge of the user's whereabouts (perhaps derived from physical proximity information gleaned from &xep0054; or &xep0080; data)</li>
@ -93,7 +93,7 @@
id='poke1'> id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/> <poke xmlns='http://jabber.org/protocol/poke'/>
</presence> </presence>
]]></example> ]]></example>
<p>The server SHOULD NOT wait an inordinate amount of time before returning the presence information (e.g., usually not more than two minutes), but the timeout period SHOULD be configurable. If the request times out, the server SHOULD return a "Request Timeout" error to the requesting entity:</p> <p>The server SHOULD NOT wait an inordinate amount of time before returning the presence information (e.g., usually not more than two minutes), but the timeout period SHOULD be configurable. If the request times out, the server SHOULD return a "Request Timeout" error to the requesting entity:</p>
<example caption='Server returns request timeout error'><![CDATA[ <example caption='Server returns request timeout error'><![CDATA[
<presence <presence
@ -107,7 +107,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
<p>The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this document (though this seems like a sensible application of the &xep0060; protocol):</p> <p>The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this document (though this seems like a sensible application of the &xep0060; protocol):</p>
<example caption='Server returns gone error'><![CDATA[ <example caption='Server returns gone error'><![CDATA[
<presence <presence
@ -124,7 +124,7 @@
</text> </text>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='IQ' anchor='protocol-iq'> <section2 topic='IQ' anchor='protocol-iq'>
<p>If the requesting entity knows at least one resource with which the user is currently connected, it MAY send an IQ to the user's full JID (&lt;user@host/resource&gt;) instead of sending a probe to the user's server.</p> <p>If the requesting entity knows at least one resource with which the user is currently connected, it MAY send an IQ to the user's full JID (&lt;user@host/resource&gt;) instead of sending a probe to the user's server.</p>
@ -136,7 +136,7 @@
<poke xmlns='http://jabber.org/protocol/poke' <poke xmlns='http://jabber.org/protocol/poke'
method='taste'/> method='taste'/>
</iq> </iq>
]]></example> ]]></example>
<p>The same errors as shown above for presence stanzas SHOULD be used by clients responding to IQ stanzas containing POKE protocols (e.g., "Request Timeout" if the user cannot be found in some reasonable period of time), and therefore are not repeated here.</p> <p>The same errors as shown above for presence stanzas SHOULD be used by clients responding to IQ stanzas containing POKE protocols (e.g., "Request Timeout" if the user cannot be found in some reasonable period of time), and therefore are not repeated here.</p>
<p>Note that the preceding example includes the optional 'method' attribute. If the target entity does not support the specified method, it MAY return a "Feature Not Implemented" error:</p> <p>Note that the preceding example includes the optional 'method' attribute. If the target entity does not support the specified method, it MAY return a "Feature Not Implemented" error:</p>
<example caption='Client returns feature not implemented error'><![CDATA[ <example caption='Client returns feature not implemented error'><![CDATA[
@ -150,7 +150,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Alternatively, it MAY choose to use some other method that it does implement, in which case it SHOULD specify the method used in the IQ result (this is the recommended behavior).</p> <p>Alternatively, it MAY choose to use some other method that it does implement, in which case it SHOULD specify the method used in the IQ result (this is the recommended behavior).</p>
<p>If the client determines that the user is physically present, it SHOULD return presence to the requesting entity (subject to privacy lists and any other appropriate access controls):</p> <p>If the client determines that the user is physically present, it SHOULD return presence to the requesting entity (subject to privacy lists and any other appropriate access controls):</p>
<example caption='Client returns success'><![CDATA[ <example caption='Client returns success'><![CDATA[
@ -161,7 +161,7 @@
<poke xmlns='http://jabber.org/protocol/poke' <poke xmlns='http://jabber.org/protocol/poke'
method='touch'/> method='touch'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Methods' anchor='protocol-methods'> <section2 topic='Methods' anchor='protocol-methods'>
<p>The following values of the 'method' attribute are defined and SHOULD be supported by a compliant implementation:</p> <p>The following values of the 'method' attribute are defined and SHOULD be supported by a compliant implementation:</p>
@ -238,6 +238,6 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

222
xep-0133.xml
View File

@ -146,7 +146,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#add-user'/> node='http://jabber.org/protocol/admin#add-user'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Add User Form to Admin'><![CDATA[ <example caption='Service Returns Add User Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -187,7 +187,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Add User Form to Service'><![CDATA[ <example caption='Admin Submits Add User Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='add-user-2' id='add-user-2'
@ -222,7 +222,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='add-user-2' id='add-user-2'
@ -234,7 +234,7 @@
sessionid='add-user:20040408T0337Z' sessionid='add-user:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
<p>Notification of completion MAY include the processed data in a data form of type "result".</p> <p>Notification of completion MAY include the processed data in a data form of type "result".</p>
</section2> </section2>
<section2 topic='Delete User' anchor='delete-user'> <section2 topic='Delete User' anchor='delete-user'>
@ -250,7 +250,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#delete-user'/> node='http://jabber.org/protocol/admin#delete-user'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Delete User Form to Admin'><![CDATA[ <example caption='Service Returns Delete User Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -276,7 +276,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Delete User Form to Service'><![CDATA[ <example caption='Admin Submits Delete User Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -297,7 +297,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='delete-user-2' id='delete-user-2'
@ -309,7 +309,7 @@
sessionid='delete-user:20040408T0337Z' sessionid='delete-user:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Disable User' anchor='disable-user'> <section2 topic='Disable User' anchor='disable-user'>
<p>An administrator may need to temporarily disable a user account. Disabling a user MUST result in the termination of any active sessions for the user and in the prevention of further user logins until the account is re-enabled (this can be thought of as "banning" the user). However, it MUST NOT result in the destruction of any implementation-specific data for the account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#disable-user".</p> <p>An administrator may need to temporarily disable a user account. Disabling a user MUST result in the termination of any active sessions for the user and in the prevention of further user logins until the account is re-enabled (this can be thought of as "banning" the user). However, it MUST NOT result in the destruction of any implementation-specific data for the account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#disable-user".</p>
@ -324,7 +324,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#disable-user'/> node='http://jabber.org/protocol/admin#disable-user'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Disable User Form to Admin'><![CDATA[ <example caption='Service Returns Disable User Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -350,7 +350,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Disable User Form to Service'><![CDATA[ <example caption='Admin Submits Disable User Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -371,7 +371,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='disable-user-2' id='disable-user-2'
@ -383,7 +383,7 @@
sessionid='disable-user:20040408T0337Z' sessionid='disable-user:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Re-Enable User' anchor='reenable-user'> <section2 topic='Re-Enable User' anchor='reenable-user'>
<p>An administrator may need to re-enable a user account that had been temporarily disabled. Re-enabling a user MUST result in granting the user the ability to access the service again. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#reenable-user".</p> <p>An administrator may need to re-enable a user account that had been temporarily disabled. Re-enabling a user MUST result in granting the user the ability to access the service again. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#reenable-user".</p>
@ -398,7 +398,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#reenable-user'/> node='http://jabber.org/protocol/admin#reenable-user'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Re-Enable User Form to Admin'><![CDATA[ <example caption='Service Returns Re-Enable User Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -424,7 +424,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Re-Enable User Form to Service'><![CDATA[ <example caption='Admin Submits Re-Enable User Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -445,7 +445,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='reenable-user-2' id='reenable-user-2'
@ -457,7 +457,7 @@
sessionid='reenable-user:20040408T0337Z' sessionid='reenable-user:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='End User Session' anchor='end-user-session'> <section2 topic='End User Session' anchor='end-user-session'>
<p>An administrator may need to terminate one or all of the user's current sessions, but allow future logins (this can be thought of as "kicking" rather than "banning" the user). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#end-user-session".</p> <p>An administrator may need to terminate one or all of the user's current sessions, but allow future logins (this can be thought of as "kicking" rather than "banning" the user). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#end-user-session".</p>
@ -472,7 +472,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#end-user-session'/> node='http://jabber.org/protocol/admin#end-user-session'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns End User Session Form to Admin'><![CDATA[ <example caption='Service Returns End User Session Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -498,7 +498,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the JID is of the form &lt;user@host&gt;, the service MUST end all of the user's sessions; if the JID is of the form &lt;user@host/resource&gt;, the service MUST end only the session associated with that resource.</p> <p>Note: If the JID is of the form &lt;user@host&gt;, the service MUST end all of the user's sessions; if the JID is of the form &lt;user@host/resource&gt;, the service MUST end only the session associated with that resource.</p>
<example caption='Admin Submits End User Session Form to Service'><![CDATA[ <example caption='Admin Submits End User Session Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -519,7 +519,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='end-user-session-2' id='end-user-session-2'
@ -531,7 +531,7 @@
sessionid='end-user-session:20040408T0337Z' sessionid='end-user-session:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get User Password' anchor='get-user-password'> <section2 topic='Get User Password' anchor='get-user-password'>
<p>An administrator may need to retrieve a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-password".</p> <p>An administrator may need to retrieve a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-password".</p>
@ -546,7 +546,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-user-password'/> node='http://jabber.org/protocol/admin#get-user-password'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Get User Password Form to Admin'><![CDATA[ <example caption='Service Returns Get User Password Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -572,7 +572,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Get User Password Form to Service'><![CDATA[ <example caption='Admin Submits Get User Password Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -593,7 +593,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Naturally, the data form included in the IQ result will include the user's password.</p> <p>Naturally, the data form included in the IQ result will include the user's password.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -618,7 +618,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Change User Password' anchor='change-user-password'> <section2 topic='Change User Password' anchor='change-user-password'>
<p>An administrator may need to change a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#change-user-password".</p> <p>An administrator may need to change a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#change-user-password".</p>
@ -633,7 +633,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#change-user-password'/> node='http://jabber.org/protocol/admin#change-user-password'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Change User Password Form to Admin'><![CDATA[ <example caption='Service Returns Change User Password Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -664,7 +664,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Change User Password Form to Service'><![CDATA[ <example caption='Admin Submits Change User Password Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -688,7 +688,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='change-user-password-2' id='change-user-password-2'
@ -700,7 +700,7 @@
sessionid='change-user-password:20040408T0337Z' sessionid='change-user-password:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get User Roster' anchor='get-user-roster'> <section2 topic='Get User Roster' anchor='get-user-roster'>
<p>An administrator may need to retrieve a user's roster (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-roster".</p> <p>An administrator may need to retrieve a user's roster (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-roster".</p>
@ -715,7 +715,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-user-roster'/> node='http://jabber.org/protocol/admin#get-user-roster'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Get User Roster Form to Admin'><![CDATA[ <example caption='Service Returns Get User Roster Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -741,7 +741,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Get User Roster Form to Service'><![CDATA[ <example caption='Admin Submits Get User Roster Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -762,7 +762,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &xmppim;.</p> <p>The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &xmppim;.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -802,7 +802,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get User Last Login Time' anchor='get-user-lastlogin'> <section2 topic='Get User Last Login Time' anchor='get-user-lastlogin'>
<p>An administrator may need to retrieve a user's last login time (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-lastlogin".</p> <p>An administrator may need to retrieve a user's last login time (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-lastlogin".</p>
@ -817,7 +817,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-user-lastlogin'/> node='http://jabber.org/protocol/admin#get-user-lastlogin'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Get User Last Login Form to Admin'><![CDATA[ <example caption='Service Returns Get User Last Login Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -843,7 +843,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p> <p>Note: If the entity is an end user, the JID SHOULD be of the form &lt;user@host&gt;, not &lt;user@host/resource&gt;.</p>
<example caption='Admin Submits Get User Last Login Form to Service'><![CDATA[ <example caption='Admin Submits Get User Last Login Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
@ -864,7 +864,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The data form included in the IQ result will include the user's last login time (which SHOULD conform to the DateTime profile specified in &xep0082;).</p> <p>The data form included in the IQ result will include the user's last login time (which SHOULD conform to the DateTime profile specified in &xep0082;).</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -889,7 +889,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get User Statistics' anchor='get-user-stats'> <section2 topic='Get User Statistics' anchor='get-user-stats'>
<p>An administrator may want to gather statistics about a particular user's interaction with the service (roster size, bandwidth usage, logins, IP address, etc.). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#user-stats".</p> <p>An administrator may want to gather statistics about a particular user's interaction with the service (roster size, bandwidth usage, logins, IP address, etc.). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#user-stats".</p>
@ -904,7 +904,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#user-stats'/> node='http://jabber.org/protocol/admin#user-stats'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns User Statistics Form to Admin'><![CDATA[ <example caption='Service Returns User Statistics Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -930,7 +930,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits User Statistics Form to Service'><![CDATA[ <example caption='Admin Submits User Statistics Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='user-stats-2' id='user-stats-2'
@ -950,7 +950,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='user-stats-2' id='user-stats-2'
@ -984,7 +984,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Edit Blacklist' anchor='edit-blacklist'> <section2 topic='Edit Blacklist' anchor='edit-blacklist'>
<p>The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc6120;; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p> <p>The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc6120;; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p>
@ -1000,7 +1000,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#edit-blacklist'/> node='http://jabber.org/protocol/admin#edit-blacklist'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Edit Blacklist Form to Admin'><![CDATA[ <example caption='Service Returns Edit Blacklist Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1028,7 +1028,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Edit Blacklist Form to Service'><![CDATA[ <example caption='Admin Submits Edit Blacklist Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='edit-blacklist-2' id='edit-blacklist-2'
@ -1050,7 +1050,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='edit-blacklist-2' id='edit-blacklist-2'
@ -1062,7 +1062,7 @@
sessionid='edit-blacklist:20040408T0337Z' sessionid='edit-blacklist:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Edit Whitelist' anchor='edit-whitelist'> <section2 topic='Edit Whitelist' anchor='edit-whitelist'>
<p>The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in <cite>RFC 6120</cite>; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p> <p>The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in <cite>RFC 6120</cite>; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p>
@ -1078,7 +1078,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#edit-whitelist'/> node='http://jabber.org/protocol/admin#edit-whitelist'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Edit Whitelist Form to Admin'><![CDATA[ <example caption='Service Returns Edit Whitelist Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1109,7 +1109,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Edit Whitelist Form to Service'><![CDATA[ <example caption='Admin Submits Edit Whitelist Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='edit-whitelist-2' id='edit-whitelist-2'
@ -1132,7 +1132,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='edit-whitelist-2' id='edit-whitelist-2'
@ -1144,7 +1144,7 @@
sessionid='edit-whitelist:20040408T0337Z' sessionid='edit-whitelist:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get Number of Registered Users' anchor='get-registered-users-num'> <section2 topic='Get Number of Registered Users' anchor='get-registered-users-num'>
<p>It may be helpful to enable an administrator to retrieve the number of registered users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-num".</p> <p>It may be helpful to enable an administrator to retrieve the number of registered users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-num".</p>
@ -1159,7 +1159,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-num'/> node='http://jabber.org/protocol/admin#get-registered-users-num'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of registered users.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of registered users.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1182,7 +1182,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get Number of Disabled Users' anchor='get-disabled-users-num'> <section2 topic='Get Number of Disabled Users' anchor='get-disabled-users-num'>
<p>Given that admins may be able to disable user accounts, it may be helpful to enable an administrator to retrieve the number of disabled users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-disabled-users-num".</p> <p>Given that admins may be able to disable user accounts, it may be helpful to enable an administrator to retrieve the number of disabled users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-disabled-users-num".</p>
@ -1197,7 +1197,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-num'/> node='http://jabber.org/protocol/admin#get-disabled-users-num'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of disabled users.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of disabled users.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1220,7 +1220,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get Number of Online Users' anchor='get-online-users-num'> <section2 topic='Get Number of Online Users' anchor='get-online-users-num'>
<p>It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".</p> <p>It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".</p>
@ -1235,7 +1235,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-online-users-num'/> node='http://jabber.org/protocol/admin#get-online-users-num'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of online users.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of online users.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1258,7 +1258,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get Number of Active Users' anchor='get-active-users-num'> <section2 topic='Get Number of Active Users' anchor='get-active-users-num'>
<p>Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are active at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-active-users-num".</p> <p>Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are active at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-active-users-num".</p>
@ -1273,7 +1273,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-active-users-num'/> node='http://jabber.org/protocol/admin#get-active-users-num'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of active users.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of active users.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1296,7 +1296,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get Number of Idle Users' anchor='get-idle-users-num'> <section2 topic='Get Number of Idle Users' anchor='get-idle-users-num'>
<p>Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are idle at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-idle-users-num".</p> <p>Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are idle at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-idle-users-num".</p>
@ -1311,7 +1311,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-idle-users-num'/> node='http://jabber.org/protocol/admin#get-idle-users-num'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of idle users.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply return the number of idle users.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1334,7 +1334,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Get List of Registered Users' anchor='get-registered-users-list'> <section2 topic='Get List of Registered Users' anchor='get-registered-users-list'>
<p>On a server or service without many registered users, it may be helpful to enable an administrator to retrieve a list of all registered users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-list".</p> <p>On a server or service without many registered users, it may be helpful to enable an administrator to retrieve a list of all registered users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-list".</p>
@ -1349,7 +1349,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-list'/> node='http://jabber.org/protocol/admin#get-registered-users-list'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p>
<ol> <ol>
<li>If there are not many registered users, the service MAY simply return the list of registered users.</li> <li>If there are not many registered users, the service MAY simply return the list of registered users.</li>
@ -1388,7 +1388,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Get Registered Users Form to Service'><![CDATA[ <example caption='Admin Submits Get Registered Users Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='get-registered-users-list-2' id='get-registered-users-list-2'
@ -1408,7 +1408,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='get-registered-users-list-2' id='get-registered-users-list-2'
@ -1450,7 +1450,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p> <p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p>
<p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p> <p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p>
</section2> </section2>
@ -1467,7 +1467,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-list'/> node='http://jabber.org/protocol/admin#get-disabled-users-list'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p>
<ol> <ol>
<li>If there are not many disabled users, the service MAY simply return the list of disabled users.</li> <li>If there are not many disabled users, the service MAY simply return the list of disabled users.</li>
@ -1506,7 +1506,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Get Disabled Users Form to Service'><![CDATA[ <example caption='Admin Submits Get Disabled Users Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='get-disabled-users-list-2' id='get-disabled-users-list-2'
@ -1526,7 +1526,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='get-disabled-users-list-2' id='get-disabled-users-list-2'
@ -1549,7 +1549,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p> <p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p>
<p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p> <p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p>
</section2> </section2>
@ -1566,7 +1566,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-online-users-list'/> node='http://jabber.org/protocol/admin#get-online-users-list'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p>
<ol> <ol>
<li>If there are not many online users, the service MAY simply return the list of online users.</li> <li>If there are not many online users, the service MAY simply return the list of online users.</li>
@ -1605,7 +1605,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Get Online Users Form to Service'><![CDATA[ <example caption='Admin Submits Get Online Users Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='get-online-users-list-2' id='get-online-users-list-2'
@ -1625,7 +1625,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='get-online-users-list-2' id='get-online-users-list-2'
@ -1658,7 +1658,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p> <p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p>
<p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p> <p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p>
</section2> </section2>
@ -1675,7 +1675,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-active-users'/> node='http://jabber.org/protocol/admin#get-active-users'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p>
<ol> <ol>
<li>If there are not many active users, the service MAY simply return the list of active users.</li> <li>If there are not many active users, the service MAY simply return the list of active users.</li>
@ -1714,7 +1714,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Get Active Users Form to Service'><![CDATA[ <example caption='Admin Submits Get Active Users Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='get-active-users-2' id='get-active-users-2'
@ -1734,7 +1734,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='get-active-users-2' id='get-active-users-2'
@ -1760,7 +1760,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p> <p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p>
<p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p> <p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p>
</section2> </section2>
@ -1777,7 +1777,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#get-idle-users'/> node='http://jabber.org/protocol/admin#get-idle-users'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD do one of the following:</p>
<ol> <ol>
<li>If there are not many idle users, the service MAY simply return the list of idle users.</li> <li>If there are not many idle users, the service MAY simply return the list of idle users.</li>
@ -1816,7 +1816,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Get Idle Users Form to Service'><![CDATA[ <example caption='Admin Submits Get Idle Users Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='get-idle-users-2' id='get-idle-users-2'
@ -1836,7 +1836,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='get-idle-users-2' id='get-idle-users-2'
@ -1864,7 +1864,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p> <p>The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.</p>
<p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p> <p>The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.</p>
</section2> </section2>
@ -1881,7 +1881,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#announce'/> node='http://jabber.org/protocol/admin#announce'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Announce Form to Admin'><![CDATA[ <example caption='Service Returns Announce Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1910,7 +1910,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Announce Form to Service'><![CDATA[ <example caption='Admin Submits Announce Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='announce-2' id='announce-2'
@ -1932,7 +1932,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='announce-2' id='announce-2'
@ -1944,7 +1944,7 @@
sessionid='announce:20040408T0337Z' sessionid='announce:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Set Message of the Day' anchor='set-motd'> <section2 topic='Set Message of the Day' anchor='set-motd'>
<p>Administrators of some existing Jabber servers have found it useful to be able to send a "message of the day" that is delivered to any user who logs in to the server that day (e.g., to announce service changes); <p>Administrators of some existing Jabber servers have found it useful to be able to send a "message of the day" that is delivered to any user who logs in to the server that day (e.g., to announce service changes);
@ -1961,7 +1961,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#set-motd'/> node='http://jabber.org/protocol/admin#set-motd'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns MOTD Form to Admin'><![CDATA[ <example caption='Service Returns MOTD Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -1989,7 +1989,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits MOTD Form to Service'><![CDATA[ <example caption='Admin Submits MOTD Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='set-motd-2' id='set-motd-2'
@ -2013,7 +2013,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='set-motd-2' id='set-motd-2'
@ -2025,7 +2025,7 @@
sessionid='set-motd:20040408T0337Z' sessionid='set-motd:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Edit Message of the Day' anchor='edit-motd'> <section2 topic='Edit Message of the Day' anchor='edit-motd'>
<p>After setting a message of the day, an administrator may want to edit that message (e.g., in order to correct an error). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-motd".</p> <p>After setting a message of the day, an administrator may want to edit that message (e.g., in order to correct an error). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-motd".</p>
@ -2040,7 +2040,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#edit-motd'/> node='http://jabber.org/protocol/admin#edit-motd'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form, which SHOULD include the current message of the day if one has already been set.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form, which SHOULD include the current message of the day if one has already been set.</p>
<example caption='Service Returns MOTD Form to Admin'><![CDATA[ <example caption='Service Returns MOTD Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2073,7 +2073,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits MOTD Form to Service'><![CDATA[ <example caption='Admin Submits MOTD Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='edit-motd-2' id='edit-motd-2'
@ -2097,7 +2097,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='edit-motd-2' id='edit-motd-2'
@ -2109,7 +2109,7 @@
sessionid='edit-motd:20040408T0337Z' sessionid='edit-motd:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Delete Message of the Day' anchor='delete-motd'> <section2 topic='Delete Message of the Day' anchor='delete-motd'>
<p>Sometimes a previously-set "message of the day" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-motd".</p> <p>Sometimes a previously-set "message of the day" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-motd".</p>
@ -2124,7 +2124,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#delete-motd'/> node='http://jabber.org/protocol/admin#delete-motd'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply delete the message of the day.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply delete the message of the day.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2137,7 +2137,7 @@
sessionid='delete-motd:20040408T0337Z' sessionid='delete-motd:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Set Welcome Message' anchor='set-welcome'> <section2 topic='Set Welcome Message' anchor='set-welcome'>
<p>Some existing Jabber servers send an informative "welcome message" to newly registered users of the server when they first log in; this concept can be extended to any service (such as a multi-user chat service or a gateway to a foreign IM service). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#set-welcome".</p> <p>Some existing Jabber servers send an informative "welcome message" to newly registered users of the server when they first log in; this concept can be extended to any service (such as a multi-user chat service or a gateway to a foreign IM service). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#set-welcome".</p>
@ -2152,7 +2152,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#set-welcome'/> node='http://jabber.org/protocol/admin#set-welcome'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form, which SHOULD include the current welcome message if one has already been set.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form, which SHOULD include the current welcome message if one has already been set.</p>
<example caption='Service Returns Welcome Message Form to Admin'><![CDATA[ <example caption='Service Returns Welcome Message Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2183,7 +2183,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Welcome Message Form to Service'><![CDATA[ <example caption='Admin Submits Welcome Message Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='set-welcome-2' id='set-welcome-2'
@ -2206,7 +2206,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='set-welcome-2' id='set-welcome-2'
@ -2218,7 +2218,7 @@
sessionid='set-welcome:20040408T0337Z' sessionid='set-welcome:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Delete Welcome Message' anchor='delete-welcome'> <section2 topic='Delete Welcome Message' anchor='delete-welcome'>
<p>Sometimes a previously-set "welcome message" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-welcome".</p> <p>Sometimes a previously-set "welcome message" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-welcome".</p>
@ -2233,7 +2233,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#delete-welcome'/> node='http://jabber.org/protocol/admin#delete-welcome'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply delete the welcome message.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD simply delete the welcome message.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2246,7 +2246,7 @@
sessionid='delete-welcome:20040408T0337Z' sessionid='delete-welcome:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Edit Admin List' anchor='edit-admin'> <section2 topic='Edit Admin List' anchor='edit-admin'>
<p>An administrator may want to directly edit the list of users who have administrative privileges. Whether there are distinctions between service-level administrators (e.g., owner, admin, moderator), and thus in what types of administrators are allowed to edit administrative privileges, is a matter for the implementation or local service policy and is not specified herein. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-admin".</p> <p>An administrator may want to directly edit the list of users who have administrative privileges. Whether there are distinctions between service-level administrators (e.g., owner, admin, moderator), and thus in what types of administrators are allowed to edit administrative privileges, is a matter for the implementation or local service policy and is not specified herein. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-admin".</p>
@ -2261,7 +2261,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#edit-admin'/> node='http://jabber.org/protocol/admin#edit-admin'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Edit Admin List Form to Admin'><![CDATA[ <example caption='Service Returns Edit Admin List Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2291,7 +2291,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Edit Admin List Form to Service'><![CDATA[ <example caption='Admin Submits Edit Admin List Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='edit-admin-2' id='edit-admin-2'
@ -2312,7 +2312,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='edit-admin-2' id='edit-admin-2'
@ -2324,7 +2324,7 @@
sessionid='edit-admin:20040408T0337Z' sessionid='edit-admin:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Restart Service' anchor='restart'> <section2 topic='Restart Service' anchor='restart'>
<p>A service may allow an administrator to restart the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#restart".</p> <p>A service may allow an administrator to restart the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#restart".</p>
@ -2339,7 +2339,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#restart'/> node='http://jabber.org/protocol/admin#restart'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Restart Form to Admin'><![CDATA[ <example caption='Service Returns Restart Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2374,7 +2374,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Restart Form to Service'><![CDATA[ <example caption='Admin Submits Restart Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='restart-2' id='restart-2'
@ -2398,7 +2398,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='restart-2' id='restart-2'
@ -2410,7 +2410,7 @@
sessionid='restart:20040408T0337Z' sessionid='restart:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Shut Down Service' anchor='shutdown'> <section2 topic='Shut Down Service' anchor='shutdown'>
<p>A service may allow an administrator to shut down the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#shutdown".</p> <p>A service may allow an administrator to shut down the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#shutdown".</p>
@ -2425,7 +2425,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/admin#shutdown'/> node='http://jabber.org/protocol/admin#shutdown'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p> <p>Unless an error occurs (see the <link url='#errors'>Error Handling</link> section below), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Shut Down Form to Admin'><![CDATA[ <example caption='Service Returns Shut Down Form to Admin'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
@ -2460,7 +2460,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Admin Submits Shut Down Form to Service'><![CDATA[ <example caption='Admin Submits Shut Down Form to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe' <iq from='bard@shakespeare.lit/globe'
id='shutdown-2' id='shutdown-2'
@ -2484,7 +2484,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[ <example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='shutdown-2' id='shutdown-2'
@ -2496,7 +2496,7 @@
sessionid='shutdown:20040408T0337Z' sessionid='shutdown:20040408T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Error Handling' anchor='errors'> <section1 topic='Error Handling' anchor='errors'>
@ -2638,7 +2638,7 @@
type='jid-multi' type='jid-multi'
label='A list of entities with whom communication is allowed'/> label='A list of entities with whom communication is allowed'/>
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema'> <section1 topic='XML Schema'>

72
xep-0135.xml
View File

@ -54,7 +54,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Room Returns Info'><![CDATA[ <example caption='Room Returns Info'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -66,7 +66,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>This document stipulates that communications regarding files MUST occur by sending stanzas to the well-known service discovery node "files" (or sub-nodes thereof as defined below). Therefore, even if (as in the foregoing example) the file owner directly supports the protocol defined herein, the requesting entity MUST send subsequent file-related service discovery requests to the node "files" (or sub-nodes thereof). The file owner also SHOULD list that node in its response to a service discovery items request, as shown in the following example:</p> <p>This document stipulates that communications regarding files MUST occur by sending stanzas to the well-known service discovery node "files" (or sub-nodes thereof as defined below). Therefore, even if (as in the foregoing example) the file owner directly supports the protocol defined herein, the requesting entity MUST send subsequent file-related service discovery requests to the node "files" (or sub-nodes thereof). The file owner also SHOULD list that node in its response to a service discovery items request, as shown in the following example:</p>
<example caption='User Queries a Room Regarding Items'><![CDATA[ <example caption='User Queries a Room Regarding Items'><![CDATA[
<iq type='get' <iq type='get'
@ -75,7 +75,7 @@
id='disco2'> id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Room Returns Items'><![CDATA[ <example caption='Room Returns Items'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -89,7 +89,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Offering Entity is not File Owner' anchor='disco-host'> <section2 topic='Offering Entity is not File Owner' anchor='disco-host'>
<p>It is possible that the file owner does not directly support the protocol defined herein and therefore that the offering entity has a JID different from that of the file owner. In this case, the file owner MUST NOT include a feature of "http://jabber.org/protocol/files" in its response to a service discovery information request, as shown in the following example (an end user querying another end user):</p> <p>It is possible that the file owner does not directly support the protocol defined herein and therefore that the offering entity has a JID different from that of the file owner. In this case, the file owner MUST NOT include a feature of "http://jabber.org/protocol/files" in its response to a service discovery information request, as shown in the following example (an end user querying another end user):</p>
@ -100,7 +100,7 @@
id='disco3'> id='disco3'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Contact Returns Info'><![CDATA[ <example caption='Contact Returns Info'><![CDATA[
<iq type='result' <iq type='result'
from='romeo@montague.net/home' from='romeo@montague.net/home'
@ -110,7 +110,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>However, in this case the file owner SHOULD still include the offering entity (e.g., a hosting service) in its response to a service discovery items request:</p> <p>However, in this case the file owner SHOULD still include the offering entity (e.g., a hosting service) in its response to a service discovery items request:</p>
<example caption='User Queries Contact Regarding Items'><![CDATA[ <example caption='User Queries Contact Regarding Items'><![CDATA[
<iq type='get' <iq type='get'
@ -119,7 +119,7 @@
id='disco4'> id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Contact Returns Items'><![CDATA[ <example caption='Contact Returns Items'><![CDATA[
<iq type='result' <iq type='result'
from='romeo@montague.net/home' from='romeo@montague.net/home'
@ -133,7 +133,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Finding Files' anchor='find'> <section1 topic='Finding Files' anchor='find'>
@ -147,7 +147,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='files'/> node='files'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the requesting entity is not allowed to view the offering entity's files (the requesting entity is not an occupant of a chatroom, is not registered with the offering entity, is not a contact in a user's roster, etc.) or the offering entity has no files to share, the offering entity SHOULD return an empty &QUERY; element:</p> <p>If the requesting entity is not allowed to view the offering entity's files (the requesting entity is not an occupant of a chatroom, is not registered with the offering entity, is not a contact in a user's roster, etc.) or the offering entity has no files to share, the offering entity SHOULD return an empty &QUERY; element:</p>
<example caption='No Files to Share'><![CDATA[ <example caption='No Files to Share'><![CDATA[
<iq type='result' <iq type='result'
@ -157,7 +157,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='files'/> node='files'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the requesting entity is allowed to view the offering entity's files and the offering entity has files to share, the offering entity SHOULD return a list of items:</p> <p>If the requesting entity is allowed to view the offering entity's files and the offering entity has files to share, the offering entity SHOULD return a list of items:</p>
<example caption='Returning the File List'><![CDATA[ <example caption='Returning the File List'><![CDATA[
<iq type='result' <iq type='result'
@ -173,7 +173,7 @@
name='file1'/> name='file1'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The NodeID MUST begin with the string 'files' followed by the '/' character followed the name of the directory or file; further subdirectories or files within a directory MUST follow the same pattern (e.g., "files/somedir/anotherfile"). Thus the protocol defined herein enforces semantic meaning on NodeIDs; this is OPTIONAL within <strong>Service Discovery</strong> but REQUIRED by this document.</p> <p>Note: The NodeID MUST begin with the string 'files' followed by the '/' character followed the name of the directory or file; further subdirectories or files within a directory MUST follow the same pattern (e.g., "files/somedir/anotherfile"). Thus the protocol defined herein enforces semantic meaning on NodeIDs; this is OPTIONAL within <strong>Service Discovery</strong> but REQUIRED by this document.</p>
<p>If the offering entity has only a few files to share, it may be appropriate to make them available via service discovery only, thus requiring the requesting entity to "walk the tree" of directories and files as described in the <link url="#find-disco">Finding All Files via Service Discovery</link> section. However, if the offering entity has a larger number of files to share, the number of service discovery requests and responses required to "walk the tree" of all directories and files might result in excessive amounts of traffic between the requesting entity and the offering entity; in this case, the offering entity SHOULD provide a "tree file" that defines the hierarchy of directories and files in the standardized format specified in the <link url="#find-tree">Retrieving the Tree File</link> section. The number of files that counts as "large" is not defined herein and is left up to the implementation or deployment; in practice, it is RECOMMENDED for the offering entity to provide a tree file if it has more than five (5) files to share.</p> <p>If the offering entity has only a few files to share, it may be appropriate to make them available via service discovery only, thus requiring the requesting entity to "walk the tree" of directories and files as described in the <link url="#find-disco">Finding All Files via Service Discovery</link> section. However, if the offering entity has a larger number of files to share, the number of service discovery requests and responses required to "walk the tree" of all directories and files might result in excessive amounts of traffic between the requesting entity and the offering entity; in this case, the offering entity SHOULD provide a "tree file" that defines the hierarchy of directories and files in the standardized format specified in the <link url="#find-tree">Retrieving the Tree File</link> section. The number of files that counts as "large" is not defined herein and is left up to the implementation or deployment; in practice, it is RECOMMENDED for the offering entity to provide a tree file if it has more than five (5) files to share.</p>
</section2> </section2>
@ -187,7 +187,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir'/> node='files/somedir'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the item is a directory, the offering entity SHOULD return information about the directory, including an identity whose category is "filesys" and whose type is "directory":</p> <p>If the item is a directory, the offering entity SHOULD return information about the directory, including an identity whose category is "filesys" and whose type is "directory":</p>
<example caption='Returning Further Information (1)'><![CDATA[ <example caption='Returning Further Information (1)'><![CDATA[
<iq type='result' <iq type='result'
@ -199,7 +199,7 @@
<identity category='filesys' type='directory'/> <identity category='filesys' type='directory'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the requesting entity wants information about every item, it MUST query each item individually:</p> <p>If the requesting entity wants information about every item, it MUST query each item individually:</p>
<example caption='Requesting Further Information (2)'><![CDATA[ <example caption='Requesting Further Information (2)'><![CDATA[
<iq type='get' <iq type='get'
@ -209,7 +209,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/> node='files/somefile'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the item is a file, the offering entity SHOULD return information about the file, including an identity whose category is "filesys" and whose type is "file":</p> <p>If the item is a file, the offering entity SHOULD return information about the file, including an identity whose category is "filesys" and whose type is "file":</p>
<example caption='Returning Further Information (2)'><![CDATA[ <example caption='Returning Further Information (2)'><![CDATA[
<iq type='result' <iq type='result'
@ -221,7 +221,7 @@
<identity category='filesys' type='file' name='file1'/> <identity category='filesys' type='file' name='file1'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The offering entity MAY also include detailed information about the file, as described in the <link url="#find-details">Determining File Details</link> section of this document.</p> <p>Note: The offering entity MAY also include detailed information about the file, as described in the <link url="#find-details">Determining File Details</link> section of this document.</p>
<p>If the requesting entity wants to find all files, it needs to send a disco#items query to the directory:</p> <p>If the requesting entity wants to find all files, it needs to send a disco#items query to the directory:</p>
<example caption='Requesting Further Items (1)'><![CDATA[ <example caption='Requesting Further Items (1)'><![CDATA[
@ -232,7 +232,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir'/> node='files/somedir'/>
</iq> </iq>
]]></example> ]]></example>
<p>The offering entity will then return a list of files and directories contained within the queried directory:</p> <p>The offering entity will then return a list of files and directories contained within the queried directory:</p>
<example caption='Returning Further Items (1)'><![CDATA[ <example caption='Returning Further Items (1)'><![CDATA[
<iq type='result' <iq type='result'
@ -248,7 +248,7 @@
name='file2'/> name='file2'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The requesting entity then needs to send further disco#info and disco#items requests to the offering entity, specifying the appropriate service discovery nodes...</p> <p>The requesting entity then needs to send further disco#info and disco#items requests to the offering entity, specifying the appropriate service discovery nodes...</p>
<example caption='Requesting Further Information (3)'><![CDATA[ <example caption='Requesting Further Information (3)'><![CDATA[
<iq type='get' <iq type='get'
@ -258,7 +258,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir'/> node='files/somedir/anotherdir'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning Further Information (3)'><![CDATA[ <example caption='Returning Further Information (3)'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -269,7 +269,7 @@
<identity category='filesys' type='directory'/> <identity category='filesys' type='directory'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting Further Information (4)'><![CDATA[ <example caption='Requesting Further Information (4)'><![CDATA[
<iq type='get' <iq type='get'
from='hag66@shakespeare.lit/pda' from='hag66@shakespeare.lit/pda'
@ -278,7 +278,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherfile'/> node='files/somedir/anotherfile'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning Further Information (4)'><![CDATA[ <example caption='Returning Further Information (4)'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -289,7 +289,7 @@
<identity category='filesys' type='file' name='file2'/> <identity category='filesys' type='file' name='file2'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting Further Items (2)'><![CDATA[ <example caption='Requesting Further Items (2)'><![CDATA[
<iq type='get' <iq type='get'
from='hag66@shakespeare.lit/pda' from='hag66@shakespeare.lit/pda'
@ -298,7 +298,7 @@
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir/anotherdir'/> node='files/somedir/anotherdir'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning Further Items (2)'><![CDATA[ <example caption='Returning Further Items (2)'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -311,7 +311,7 @@
name='file3'/> name='file3'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting Further Information (5)'><![CDATA[ <example caption='Requesting Further Information (5)'><![CDATA[
<iq type='get' <iq type='get'
from='hag66@shakespeare.lit/pda' from='hag66@shakespeare.lit/pda'
@ -320,7 +320,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir/yetanotherfile'/> node='files/somedir/anotherdir/yetanotherfile'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning Further Information (5)'><![CDATA[ <example caption='Returning Further Information (5)'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -331,7 +331,7 @@
<identity category='filesys' type='file' name='file3'/> <identity category='filesys' type='file' name='file3'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In this scenario, we can reconstruct the file tree as follows:</p> <p>In this scenario, we can reconstruct the file tree as follows:</p>
<code><![CDATA[ <code><![CDATA[
share share
@ -340,7 +340,7 @@ share
\--anotherfile \--anotherfile
\--anotherdir \--anotherdir
\--yetanotherfile \--yetanotherfile
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Retrieving the Tree File' anchor='find-tree'> <section2 topic='Retrieving the Tree File' anchor='find-tree'>
<p>Obviously, finding all files via service discovery is a tedious process. Therefore, it is RECOMMENDED that the offering entity provide a "tree file" if it has more than five (5) files to share. The format of the tree file is defined by the 'http://jabber.org/profile/si/profile/tree-transfer' namespace that is specified in &xep0105;. The tree file MUST be named "tree.xml" and MUST be available at the well-known service discovery node "tree.xml". The offering entity MAY create a different tree file for each requesting entity (depending on the requesting entity's permissions to view certain directories and files); for this reason, the tree file SHOULD NOT be contained in the root "files" directory itself (note that its NodeID is "tree.xml", not "files/tree.xml").</p> <p>Obviously, finding all files via service discovery is a tedious process. Therefore, it is RECOMMENDED that the offering entity provide a "tree file" if it has more than five (5) files to share. The format of the tree file is defined by the 'http://jabber.org/profile/si/profile/tree-transfer' namespace that is specified in &xep0105;. The tree file MUST be named "tree.xml" and MUST be available at the well-known service discovery node "tree.xml". The offering entity MAY create a different tree file for each requesting entity (depending on the requesting entity's permissions to view certain directories and files); for this reason, the tree file SHOULD NOT be contained in the root "files" directory itself (note that its NodeID is "tree.xml", not "files/tree.xml").</p>
@ -353,7 +353,7 @@ share
<query xmlns='http://jabber.org/protocol/disco#items' <query xmlns='http://jabber.org/protocol/disco#items'
node='files'/> node='files'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning the File List'><![CDATA[ <example caption='Returning the File List'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -371,7 +371,7 @@ share
name='Tree File'/> name='Tree File'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the offering entity includes a service discovery item whose NodeID is "tree.xml", the requesting entity SHOULD retrieve that file (using the protocol specified in the <link url="retrieve">Retrieving a File</link> section) before sending any further service discovery requests to the offering entity.</p> <p>If the offering entity includes a service discovery item whose NodeID is "tree.xml", the requesting entity SHOULD retrieve that file (using the protocol specified in the <link url="retrieve">Retrieving a File</link> section) before sending any further service discovery requests to the offering entity.</p>
<p>The following example shows the exact format of the tree file that would represent the file and directory hierarchy discovered via service discovery in the preceding section:</p> <p>The following example shows the exact format of the tree file that would represent the file and directory hierarchy discovered via service discovery in the preceding section:</p>
<example caption='A Tree File'><![CDATA[ <example caption='A Tree File'><![CDATA[
@ -388,7 +388,7 @@ share
</directory> </directory>
</directory> </directory>
</tree> </tree>
]]></example> ]]></example>
<p>If the offering entity provides a tree file, it is RECOMMENDED (but not required) for the offering entity to also make information about its files discoverable via <strong>Service Discovery</strong> as described in the following section.</p> <p>If the offering entity provides a tree file, it is RECOMMENDED (but not required) for the offering entity to also make information about its files discoverable via <strong>Service Discovery</strong> as described in the following section.</p>
</section2> </section2>
<section2 topic='Determining File Details' anchor='find-details'> <section2 topic='Determining File Details' anchor='find-details'>
@ -402,7 +402,7 @@ share
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/> node='files/somefile'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Returning Detailed File Information'><![CDATA[ <example caption='Returning Detailed File Information'><![CDATA[
<iq type='result' <iq type='result'
from='darkcave@macbeth.shakespeare.lit' from='darkcave@macbeth.shakespeare.lit'
@ -433,7 +433,7 @@ share
</x> </x>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The fields shown are RECOMMENDED, and are specified more fully in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p> <p>The fields shown are RECOMMENDED, and are specified more fully in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
</section2> </section2>
</section1> </section1>
@ -447,12 +447,12 @@ share
<retrieve xmlns='http://jabber.org/protocol/files' <retrieve xmlns='http://jabber.org/protocol/files'
node='files/somefile'/> node='files/somefile'/>
</iq> </iq>
]]></example> ]]></example>
<p>Note: If the requested file was found by means of the tree file rather than service discovery, the NodeID of the retrieve request MUST be constructed according to the rules specified above for service discovery NodeIDs (i.e., 'files' followed by the '/' character followed by the name of the directory or file, followed by additional '/' characters and subdirectory or file names as needed).</p> <p>Note: If the requested file was found by means of the tree file rather than service discovery, the NodeID of the retrieve request MUST be constructed according to the rules specified above for service discovery NodeIDs (i.e., 'files' followed by the '/' character followed by the name of the directory or file, followed by additional '/' characters and subdirectory or file names as needed).</p>
<p>If the offering entity agrees to share the file with the requesting entity, it MUST return an IQ result to the requesting entity and then immediately initiate a file transfer to the requesting entity following the protocol defined in &xep0096;:</p> <p>If the offering entity agrees to share the file with the requesting entity, it MUST return an IQ result to the requesting entity and then immediately initiate a file transfer to the requesting entity following the protocol defined in &xep0096;:</p>
<example caption='Offering Entity Agrees to Share File'><![CDATA[ <example caption='Offering Entity Agrees to Share File'><![CDATA[
<iq type='result' id='retrieve1'/> <iq type='result' id='retrieve1'/>
]]></example> ]]></example>
<example caption='Offering Entity Initiates File Transfer'> <example caption='Offering Entity Initiates File Transfer'>
<![CDATA[ <![CDATA[
<iq type='set' <iq type='set'
@ -476,7 +476,7 @@ share
</feature> </feature>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>The value of the &lt;si/&gt; element's 'id' attribute MUST be the same as the value of the 'sid' attribute communicated in the tree file or the 'name' attribute communicated via service discovery; for this reason, the service discovery 'name' attribute is REQUIRED for NodeIDs that correspond to files, and its value MUST follow the rules for the 'sid' attribute specified in XEP-0105.</p> <p>The value of the &lt;si/&gt; element's 'id' attribute MUST be the same as the value of the 'sid' attribute communicated in the tree file or the 'name' attribute communicated via service discovery; for this reason, the service discovery 'name' attribute is REQUIRED for NodeIDs that correspond to files, and its value MUST follow the rules for the 'sid' attribute specified in XEP-0105.</p>
<p>Upon receiving the file transfer initiation from the offering entity, the requesting entity SHOULD check the SI 'id' in order to correlate the file transfer with the request; if there is a match, the requesting entity SHOULD silently accept the file transfer and not require intervention by a human before proceeding.</p> <p>Upon receiving the file transfer initiation from the offering entity, the requesting entity SHOULD check the SI 'id' in order to correlate the file transfer with the request; if there is a match, the requesting entity SHOULD silently accept the file transfer and not require intervention by a human before proceeding.</p>
<p>If the offering entity does not agree to share the file with the requesting entity, it MUST return an appropriate IQ error to the requesting entity, such as "Not Authorized", "Forbidden", "Payment Required", "Registration Required", or "Not Found" (see &xep0086; regarding error syntax).</p> <p>If the offering entity does not agree to share the file with the requesting entity, it MUST return an appropriate IQ error to the requesting entity, such as "Not Authorized", "Forbidden", "Payment Required", "Registration Required", or "Not Found" (see &xep0086; regarding error syntax).</p>
@ -525,7 +525,7 @@ share
type='text-single' type='text-single'
label='Equivalent to size attribute from XEP-0096'/> label='Equivalent to size attribute from XEP-0096'/>
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -555,6 +555,6 @@ share
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

126
xep-0136.xml
View File

@ -222,7 +222,7 @@
<method type='manual' use='prefer'/> <method type='manual' use='prefer'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<section3 topic='Auto Element' anchor='pref-syntax-auto'> <section3 topic='Auto Element' anchor='pref-syntax-auto'>
<p>The &lt;auto/&gt; element specifies the current <link url='#auto'>Automatic Archiving</link> settings for <em>this stream</em>.</p> <p>The &lt;auto/&gt; element specifies the current <link url='#auto'>Automatic Archiving</link> settings for <em>this stream</em>.</p>
<p>This element MUST be empty and MUST include a boolean 'save' attribute &BOOLEANNOTE; that specifies whether automatic archiving is enabled or disabled for this stream. The element MAY include a 'scope' attribute that specifies how long this setting is true. The allowable values are:</p> <p>This element MUST be empty and MUST include a boolean 'save' attribute &BOOLEANNOTE; that specifies whether automatic archiving is enabled or disabled for this stream. The element MAY include a 'scope' attribute that specifies how long this setting is true. The allowable values are:</p>
@ -341,7 +341,7 @@
<iq type='get' id='pref1'> <iq type='get' id='pref1'>
<pref xmlns='urn:xmpp:archive'/> <pref xmlns='urn:xmpp:archive'/>
</iq> </iq>
]]></example> ]]></example>
<p>The server responds with the default Save Mode and OTR Mode (a single &lt;default/&gt; element) and any specific Save Modes and OTR Modes for individual contacts (zero or more &lt;item/&gt; elements).</p> <p>The server responds with the default Save Mode and OTR Mode (a single &lt;default/&gt; element) and any specific Save Modes and OTR Modes for individual contacts (zero or more &lt;item/&gt; elements).</p>
<example caption='Server Returns Preferences'><![CDATA[ <example caption='Server Returns Preferences'><![CDATA[
<iq type='result' id='pref1' to='juliet@capulet.com/chamber'> <iq type='result' id='pref1' to='juliet@capulet.com/chamber'>
@ -356,7 +356,7 @@
<method type='manual' use='prefer'/> <method type='manual' use='prefer'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing preferences can be explained as follows:</p> <p>The foregoing preferences can be explained as follows:</p>
<ol> <ol>
<li>By default, message bodies should be saved (according the preferred method specified later), communications may be off the record if requested, and any saved messages should be expired after 1 year.</li> <li>By default, message bodies should be saved (according the preferred method specified later), communications may be off the record if requested, and any saved messages should be expired after 1 year.</li>
@ -378,7 +378,7 @@
<auto save='false'/> <auto save='false'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>Once it has received a request for archiving preferences from the client, the server MUST send any subsequent changes to any of the user's archiving preferences to the client until the stream is closed (see below). Note: changes to the &lt;auto/&gt; element MUST NOT be replicated in this way.</p> <p>Once it has received a request for archiving preferences from the client, the server MUST send any subsequent changes to any of the user's archiving preferences to the client until the stream is closed (see below). Note: changes to the &lt;auto/&gt; element MUST NOT be replicated in this way.</p>
</section2> </section2>
<section2 topic='Setting Default Modes' anchor='pref-default'> <section2 topic='Setting Default Modes' anchor='pref-default'>
@ -389,11 +389,11 @@
<default otr='prefer' save='false'/> <default otr='prefer' save='false'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>If the server can process the request, it acknowledges the change:</p> <p>If the server can process the request, it acknowledges the change:</p>
<example caption='Server Acknowledges Change'><![CDATA[ <example caption='Server Acknowledges Change'><![CDATA[
<iq type='result' id='pref2' to='juliet@capulet.com/chamber'/> <iq type='result' id='pref2' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
<p>The server then MUST inform all of the user's connected resources that have previously requested the user's archiving preferences:</p> <p>The server then MUST inform all of the user's connected resources that have previously requested the user's archiving preferences:</p>
<example caption='Server Pushes New Modes'><![CDATA[ <example caption='Server Pushes New Modes'><![CDATA[
<iq type='set' id='push1' to='juliet@capulet.com/chamber'> <iq type='set' id='push1' to='juliet@capulet.com/chamber'>
@ -407,7 +407,7 @@
<default otr='prefer' save='false'/> <default otr='prefer' save='false'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>If the server does not allow the saving of full message stanza content, the client set the value of the 'save' attribute to 'message' or 'stream', and any of the user's connected resources have <link url='#auto'>Automatic Archiving</link> enabled, then the server SHOULD return a &feature; error.</p> <p>If the server does not allow the saving of full message stanza content, the client set the value of the 'save' attribute to 'message' or 'stream', and any of the user's connected resources have <link url='#auto'>Automatic Archiving</link> enabled, then the server SHOULD return a &feature; error.</p>
<p>If administrator policies require that at least the &lt;body/&gt; elements (or the full content) of every message must be logged automatically and the client attempts to set the value of the 'save' attribute to 'false' or 'body', then the server SHOULD return a &notacceptable; error.</p> <p>If administrator policies require that at least the &lt;body/&gt; elements (or the full content) of every message must be logged automatically and the client attempts to set the value of the 'save' attribute to 'false' or 'body', then the server SHOULD return a &notacceptable; error.</p>
</section2> </section2>
@ -419,10 +419,10 @@
<item jid='romeo@montague.net' save='body' expire='604800' otr='concede'/> <item jid='romeo@montague.net' save='body' expire='604800' otr='concede'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Acknowleges Change'><![CDATA[ <example caption='Server Acknowleges Change'><![CDATA[
<iq type='result' id='pref3' to='juliet@capulet.com/chamber'/> <iq type='result' id='pref3' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
<example caption='Server Pushes New Modes'><![CDATA[ <example caption='Server Pushes New Modes'><![CDATA[
<iq type='set' id='push3' to='juliet@capulet.com/chamber'> <iq type='set' id='push3' to='juliet@capulet.com/chamber'>
<pref xmlns='urn:xmpp:archive'> <pref xmlns='urn:xmpp:archive'>
@ -435,7 +435,7 @@
<item jid='romeo@montague.net' save='body' expire='604800' otr='concede'/> <item jid='romeo@montague.net' save='body' expire='604800' otr='concede'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>The same error cases apply as when <link url='#auto'>Setting Default Modes</link>.</p> <p>The same error cases apply as when <link url='#auto'>Setting Default Modes</link>.</p>
<p>In order to remove all preferences for a contact, the client shall send an &lt;itemremove/&gt; element to the server.</p> <p>In order to remove all preferences for a contact, the client shall send an &lt;itemremove/&gt; element to the server.</p>
<example caption='Client Removes Preferences for a Contact'><![CDATA[ <example caption='Client Removes Preferences for a Contact'><![CDATA[
@ -444,10 +444,10 @@
<item jid='benvolio@montague.net'/> <item jid='benvolio@montague.net'/>
</itemremove> </itemremove>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Acknowleges Change'><![CDATA[ <example caption='Server Acknowleges Change'><![CDATA[
<iq type='result' id='remove1' to='juliet@capulet.com/chamber'/> <iq type='result' id='remove1' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Setting Modes for a Chat Session' anchor='pref-session'> <section2 topic='Setting Modes for a Chat Session' anchor='pref-session'>
<p>A client may use a similar protocol to set the Modes for a particular chat session. A chat session is identified by its unique 'thread' attributes in &lt;message&gt; stanza (see &xep0155;).</p> <p>A client may use a similar protocol to set the Modes for a particular chat session. A chat session is identified by its unique 'thread' attributes in &lt;message&gt; stanza (see &xep0155;).</p>
@ -457,10 +457,10 @@
<session thread='ffd7076498744578d10edabfe7f4a866' save='body' otr='concede'/> <session thread='ffd7076498744578d10edabfe7f4a866' save='body' otr='concede'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Acknowleges Change'><![CDATA[ <example caption='Server Acknowleges Change'><![CDATA[
<iq type='result' id='pref4' to='juliet@capulet.com/chamber'/> <iq type='result' id='pref4' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
<example caption='Server Pushes New Modes'><![CDATA[ <example caption='Server Pushes New Modes'><![CDATA[
<iq type='set' id='push5' to='juliet@capulet.com/chamber'> <iq type='set' id='push5' to='juliet@capulet.com/chamber'>
<pref xmlns='urn:xmpp:archive'> <pref xmlns='urn:xmpp:archive'>
@ -473,7 +473,7 @@
<session thread='ffd7076498744578d10edabfe7f4a866' save='body' timeout='3600' otr='concede'/> <session thread='ffd7076498744578d10edabfe7f4a866' save='body' timeout='3600' otr='concede'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<p>The same error cases apply as when <link url='#auto'>Setting Default Modes</link>.</p> <p>The same error cases apply as when <link url='#auto'>Setting Default Modes</link>.</p>
<p>In order to remove a preference for a chat session, the client shall send an &lt;sessionremove/&gt; element to the server.</p> <p>In order to remove a preference for a chat session, the client shall send an &lt;sessionremove/&gt; element to the server.</p>
<example caption='Client Removes Preferences for a Contact'><![CDATA[ <example caption='Client Removes Preferences for a Contact'><![CDATA[
@ -482,10 +482,10 @@
<session thread='ffd7076498744578d10edabfe7f4a866'/> <session thread='ffd7076498744578d10edabfe7f4a866'/>
</sessionremove> </sessionremove>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Acknowleges Change'><![CDATA[ <example caption='Server Acknowleges Change'><![CDATA[
<iq type='result' id='remove2' to='juliet@capulet.com/chamber'/> <iq type='result' id='remove2' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Setting Archiving Method Preferences' anchor='pref-archive'> <section2 topic='Setting Archiving Method Preferences' anchor='pref-archive'>
<p>The client can set one or more method preferences by sending an IQ-set containing a &lt;pref/&gt; element that in turn contains one or more &lt;method/&gt; elements.</p> <p>The client can set one or more method preferences by sending an IQ-set containing a &lt;pref/&gt; element that in turn contains one or more &lt;method/&gt; elements.</p>
@ -497,10 +497,10 @@
<method type='manual' use='prefer'/> <method type='manual' use='prefer'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Acknowleges Change'><![CDATA[ <example caption='Server Acknowleges Change'><![CDATA[
<iq type='result' id='pref5' to='juliet@capulet.com/chamber'/> <iq type='result' id='pref5' to='juliet@capulet.com/chamber'/>
]]></example> ]]></example>
<p>If the client includes less than three &lt;method/&gt; elements, the server MUST NOT modify the unspecified methods and MUST leave them as currently stored on the server. However, when the server pushes the method preferences it MUST include all of the preferences, not only those that were set by the client.</p> <p>If the client includes less than three &lt;method/&gt; elements, the server MUST NOT modify the unspecified methods and MUST leave them as currently stored on the server. However, when the server pushes the method preferences it MUST include all of the preferences, not only those that were set by the client.</p>
<example caption='Server Pushes New Method Preferences'><![CDATA[ <example caption='Server Pushes New Method Preferences'><![CDATA[
<iq type='set' id='push7' to='juliet@capulet.com/chamber'> <iq type='set' id='push7' to='juliet@capulet.com/chamber'>
@ -518,7 +518,7 @@
<method type='manual' use='prefer'/> <method type='manual' use='prefer'/>
</pref> </pref>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Server Archiving Preferences Interpretation' anchor='pref-server'> <section2 topic='Server Archiving Preferences Interpretation' anchor='pref-server'>
<p>Most archiving preferences are designed for interpretation only by the client. The server MUST NOT take into account any of the archiving preferences when server administration policies <em>require</em> that every message is to be logged automatically. Otherwise, the server MUST interpret the following archiving preferences (and SHOULD NOT interpret any other ones):</p> <p>Most archiving preferences are designed for interpretation only by the client. The server MUST NOT take into account any of the archiving preferences when server administration policies <em>require</em> that every message is to be logged automatically. Otherwise, the server MUST interpret the following archiving preferences (and SHOULD NOT interpret any other ones):</p>
@ -708,7 +708,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<p>If the collection does not exist then the server MUST create a new collection and inform the client that the collection version number is zero.</p> <p>If the collection does not exist then the server MUST create a new collection and inform the client that the collection version number is zero.</p>
<example caption='Collection created'><![CDATA[ <example caption='Collection created'><![CDATA[
<iq type='result' id='up1'> <iq type='result' id='up1'>
@ -720,7 +720,7 @@
version='0'/> version='0'/>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<p>If the collection already exists then the server MUST append the messages to the existing collection (which MAY involve adding messages that appear to be duplicates, i.e., messages that have identical &lt;from/&gt; elements, &lt;to/&gt; elements, and dateTimes).</p> <p>If the collection already exists then the server MUST append the messages to the existing collection (which MAY involve adding messages that appear to be duplicates, i.e., messages that have identical &lt;from/&gt; elements, &lt;to/&gt; elements, and dateTimes).</p>
<example caption='Messages appended to collection'><![CDATA[ <example caption='Messages appended to collection'><![CDATA[
<iq type='result' id='up1'> <iq type='result' id='up1'>
@ -732,7 +732,7 @@
version='1'/> version='1'/>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<p>Note: Clients MUST take care to append each sequence of messages to the collection before the sequence becomes so large that uploading it may violate common rate limiting restrictions (in Jabber systems, often called "karma").</p> <p>Note: Clients MUST take care to append each sequence of messages to the collection before the sequence becomes so large that uploading it may violate common rate limiting restrictions (in Jabber systems, often called "karma").</p>
<p>If the server cannot service an upload request because the collection is too large then it MUST return a &notacceptable; error:</p> <p>If the server cannot service an upload request because the collection is too large then it MUST return a &notacceptable; error:</p>
<example caption='Unsuccessful reply'><![CDATA[ <example caption='Unsuccessful reply'><![CDATA[
@ -741,7 +741,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Changing the Subject of a Collection' anchor='impl-subject'> <section2 topic='Changing the Subject of a Collection' anchor='impl-subject'>
<p>If the client specifies a new value for the 'subject' attribute of any existing collection then the server MUST update the existing value and increment the collection version. Note: The client cannot specify new values for the 'with' or 'start' attributes. The only way to change these values is to delete the collection (see <link url='#manage-remove'>Removing a Collection</link>) and then create a new one.</p> <p>If the client specifies a new value for the 'subject' attribute of any existing collection then the server MUST update the existing value and increment the collection version. Note: The client cannot specify new values for the 'with' or 'start' attributes. The only way to change these values is to delete the collection (see <link url='#manage-remove'>Removing a Collection</link>) and then create a new one.</p>
@ -753,7 +753,7 @@
subject='She speaks twice!'/> subject='She speaks twice!'/>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<example caption='Collection subject updated'><![CDATA[ <example caption='Collection subject updated'><![CDATA[
<iq type='result' id='subject1'> <iq type='result' id='subject1'>
<save xmlns='urn:xmpp:archive'> <save xmlns='urn:xmpp:archive'>
@ -763,7 +763,7 @@
version='1'/> version='1'/>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Offline Messages' anchor='impl-offline'> <section2 topic='Offline Messages' anchor='impl-offline'>
<p>The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in <cite>XEP-0082</cite>) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:</p> <p>The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in <cite>XEP-0082</cite>) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:</p>
@ -779,7 +779,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Groupchat Messages' anchor='impl-muc'> <section2 topic='Groupchat Messages' anchor='impl-muc'>
<p>A client MAY archive messages that it receives from &xep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each &lt;from/&gt; element to specify the room nickname of the message sender and MAY include a 'jid' attribute to specify the full or bare JID of the sender (if available).</p> <p>A client MAY archive messages that it receives from &xep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each &lt;from/&gt; element to specify the room nickname of the message sender and MAY include a 'jid' attribute to specify the full or bare JID of the sender (if available).</p>
@ -794,7 +794,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Linking Collections' anchor='impl-link'> <section2 topic='Linking Collections' anchor='impl-link'>
<p>Collections MAY be linked together by including a &lt;previous/&gt; and/or &lt;next/&gt; element. Each such element MUST include both a 'with' and a 'start' element to identify the other collection to which the collection is linked. For example, the &lt;previous/&gt; and &lt;next/&gt; elements in the two examples below are being used to link a groupchat between Romeo, Benvolio and Mercutio to a private chat that Romeo was having with Benvolio before they invited Mercutio to join them. Note: Collections MAY be linked in only one direction, they are not required to be double-linked in the way the examples below are.</p> <p>Collections MAY be linked together by including a &lt;previous/&gt; and/or &lt;next/&gt; element. Each such element MUST include both a 'with' and a 'start' element to identify the other collection to which the collection is linked. For example, the &lt;previous/&gt; and &lt;next/&gt; elements in the two examples below are being used to link a groupchat between Romeo, Benvolio and Mercutio to a private chat that Romeo was having with Benvolio before they invited Mercutio to join them. Note: Collections MAY be linked in only one direction, they are not required to be double-linked in the way the examples below are.</p>
@ -809,7 +809,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<example caption='Groupchat linked to earlier private chat'><![CDATA[ <example caption='Groupchat linked to earlier private chat'><![CDATA[
<iq type='set' id='link2'> <iq type='set' id='link2'>
<save xmlns='urn:xmpp:archive'> <save xmlns='urn:xmpp:archive'>
@ -822,7 +822,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<p>A collection MUST NOT contain more than one &lt;previous/&gt; and one &lt;next/&gt; element. If a &lt;previous/&gt; element is uploaded to a collection that already contains one then the older &lt;previous/&gt; element MUST be discarded. The same requirement applies for &lt;next/&gt; elements.</p> <p>A collection MUST NOT contain more than one &lt;previous/&gt; and one &lt;next/&gt; element. If a &lt;previous/&gt; element is uploaded to a collection that already contains one then the older &lt;previous/&gt; element MUST be discarded. The same requirement applies for &lt;next/&gt; elements.</p>
<p>When a collection is retrieved (see <link url='#manage-retrieve'>Retrieving a Collection</link>) the &lt;previous/&gt; and &lt;next/&gt; elements MUST appear as the first elements in the collection, whatever order they were uploaded in.</p> <p>When a collection is retrieved (see <link url='#manage-retrieve'>Retrieving a Collection</link>) the &lt;previous/&gt; and &lt;next/&gt; elements MUST appear as the first elements in the collection, whatever order they were uploaded in.</p>
<p>&lt;previous/&gt; and &lt;next/&gt; elements MAY be removed from a collection simply by uploading a &lt;previous/&gt; and/or &lt;next/&gt; element without any 'with' or 'start' attributes. Note: The server SHOULD NOT return an error if it finds that a link to be deleted does not exist.</p> <p>&lt;previous/&gt; and &lt;next/&gt; elements MAY be removed from a collection simply by uploading a &lt;previous/&gt; and/or &lt;next/&gt; element without any 'with' or 'start' attributes. Note: The server SHOULD NOT return an error if it finds that a link to be deleted does not exist.</p>
@ -836,7 +836,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Associating Attributes with a Collection' anchor='impl-form'> <section2 topic='Associating Attributes with a Collection' anchor='impl-form'>
<p>A client MAY append attributes to a collection by including an x:data form of type 'submit' (see &xep0004;) when it uploads to a collection.</p> <p>A client MAY append attributes to a collection by including an x:data form of type 'submit' (see &xep0004;) when it uploads to a collection.</p>
@ -858,7 +858,7 @@
</chat> </chat>
</save> </save>
</iq> </iq>
]]></example> ]]></example>
<p>As described in <cite>XEP-0241</cite>, the content of the uploaded x:data form MAY be encrypted.</p> <p>As described in <cite>XEP-0241</cite>, the content of the uploaded x:data form MAY be encrypted.</p>
</section2> </section2>
</section1> </section1>
@ -875,7 +875,7 @@
<body>WARNING: All messages that you send or <body>WARNING: All messages that you send or
receive will be recorded by the server.</body> receive will be recorded by the server.</body>
</message> </message>
]]></example> ]]></example>
<p>Otherwise:</p> <p>Otherwise:</p>
<ul> <ul>
<li>Automatic archiving MUST default to enabled or disabled when each stream is opened according to the last value of &lt;auto/&gt; element if 'scope' was set to 'global' (see <link url='#pref-syntax-auto'>Auto element</link>), else Automatic archiving MUST default disabled.</li> <li>Automatic archiving MUST default to enabled or disabled when each stream is opened according to the last value of &lt;auto/&gt; element if 'scope' was set to 'global' (see <link url='#pref-syntax-auto'>Auto element</link>), else Automatic archiving MUST default disabled.</li>
@ -888,7 +888,7 @@
<iq type='set' id='auto1'> <iq type='set' id='auto1'>
<auto save='true' xmlns='urn:xmpp:archive'/> <auto save='true' xmlns='urn:xmpp:archive'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the server does not support the saving of full message stanza or stream content and the user has specified the 'message' or 'stream' Save Mode in one of its <link url='#pref'>Archiving Preferences</link>, the server MUST return a &feature; error.</p> <p>If the server does not support the saving of full message stanza or stream content and the user has specified the 'message' or 'stream' Save Mode in one of its <link url='#pref'>Archiving Preferences</link>, the server MUST return a &feature; error.</p>
<example caption='Server Does Not Support Full Message or Stream Content'><![CDATA[ <example caption='Server Does Not Support Full Message or Stream Content'><![CDATA[
<iq type='error' id='auto1'> <iq type='error' id='auto1'>
@ -896,13 +896,13 @@
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>The client can disable auto-archiving by setting the 'save' attribute to "false" or "0".</p> <p>The client can disable auto-archiving by setting the 'save' attribute to "false" or "0".</p>
<example caption='Client disables auto archiving'><![CDATA[ <example caption='Client disables auto archiving'><![CDATA[
<iq type='set' id='auto3'> <iq type='set' id='auto3'>
<auto save='false' xmlns='urn:xmpp:archive'/> <auto save='false' xmlns='urn:xmpp:archive'/>
</iq> </iq>
]]></example> ]]></example>
<p>If service policies require that every message is logged automatically, the server MUST return a &notallowed; error.</p> <p>If service policies require that every message is logged automatically, the server MUST return a &notallowed; error.</p>
<example caption='Automatic Archiving is Compulsory'><![CDATA[ <example caption='Automatic Archiving is Compulsory'><![CDATA[
<iq type='error' id='auto3'> <iq type='error' id='auto3'>
@ -910,7 +910,7 @@
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Archive Management' anchor='manage'> <section1 topic='Archive Management' anchor='manage'>
@ -934,7 +934,7 @@
</set> </set>
</list> </list>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting the first page of a list with same JID between two times'><![CDATA[ <example caption='Requesting the first page of a list with same JID between two times'><![CDATA[
<iq type='get' id='period1'> <iq type='get' id='period1'>
<list xmlns='urn:xmpp:archive' <list xmlns='urn:xmpp:archive'
@ -946,7 +946,7 @@
</set> </set>
</list> </list>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting the first page of a list after a time'><![CDATA[ <example caption='Requesting the first page of a list after a time'><![CDATA[
<iq type='get' id='list1'> <iq type='get' id='list1'>
<list xmlns='urn:xmpp:archive' <list xmlns='urn:xmpp:archive'
@ -956,7 +956,7 @@
</set> </set>
</list> </list>
</iq> </iq>
]]></example> ]]></example>
<p>The server MUST list the collections (empty &lt;chat/&gt; elements including all attributes) in chronological order when responding to any request.</p> <p>The server MUST list the collections (empty &lt;chat/&gt; elements including all attributes) in chronological order when responding to any request.</p>
<p>Note: In accordance with <cite>Result Set Management</cite>, the client MUST assume that the unique IDs it receives in the &lt;first/&gt; and &lt;last/&gt; elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.</p> <p>Note: In accordance with <cite>Result Set Management</cite>, the client MUST assume that the unique IDs it receives in the &lt;first/&gt; and &lt;last/&gt; elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.</p>
<p>If no collections correspond to the request the server MUST return an empty &lt;list/&gt; element:</p> <p>If no collections correspond to the request the server MUST return an empty &lt;list/&gt; element:</p>
@ -964,7 +964,7 @@
<iq type='result' to='romeo@montague.net/orchard' id='list1'> <iq type='result' to='romeo@montague.net/orchard' id='list1'>
<list xmlns='urn:xmpp:archive'/> <list xmlns='urn:xmpp:archive'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting the second page of a list'><![CDATA[ <example caption='Requesting the second page of a list'><![CDATA[
<iq type='get' id='list2'> <iq type='get' id='list2'>
<list xmlns='urn:xmpp:archive' <list xmlns='urn:xmpp:archive'
@ -975,7 +975,7 @@
</set> </set>
</list> </list>
</iq> </iq>
]]></example> ]]></example>
<p>Refer to <cite>Result Set Management</cite> to learn more about the various ways that the pages of the list may be accessed.</p> <p>Refer to <cite>Result Set Management</cite> to learn more about the various ways that the pages of the list may be accessed.</p>
</section2> </section2>
<section2 topic='Retrieving a Collection' anchor='manage-retrieve'> <section2 topic='Retrieving a Collection' anchor='manage-retrieve'>
@ -992,7 +992,7 @@
</set> </set>
</retrieve> </retrieve>
</iq> </iq>
]]></example> ]]></example>
<example caption='Receiving the first page of a collection'><![CDATA[ <example caption='Receiving the first page of a collection'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='page1'> <iq type='result' to='romeo@montague.net/orchard' id='page1'>
<chat xmlns='urn:xmpp:archive' <chat xmlns='urn:xmpp:archive'
@ -1013,7 +1013,7 @@
</set> </set>
</chat> </chat>
</iq> </iq>
]]></example> ]]></example>
<p>Note: In accordance with <cite>Result Set Management</cite>, the client MUST assume the unique IDs it receives in the &lt;first/&gt; and &lt;last/&gt; elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.</p> <p>Note: In accordance with <cite>Result Set Management</cite>, the client MUST assume the unique IDs it receives in the &lt;first/&gt; and &lt;last/&gt; elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.</p>
<p>If the specified collection does not exist then the server MUST return an &notfound; error:</p> <p>If the specified collection does not exist then the server MUST return an &notfound; error:</p>
<example caption='Unsuccessful reply'><![CDATA[ <example caption='Unsuccessful reply'><![CDATA[
@ -1029,7 +1029,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the requested collection is empty the server MUST return an empty &lt;chat/&gt; element:</p> <p>If the requested collection is empty the server MUST return an empty &lt;chat/&gt; element:</p>
<example caption='Receiving an empty collection'><![CDATA[ <example caption='Receiving an empty collection'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='page1'> <iq type='result' to='romeo@montague.net/orchard' id='page1'>
@ -1039,7 +1039,7 @@
subject='She speaks!' subject='She speaks!'
version='5'/> version='5'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Requesting the second page of a collection'><![CDATA[ <example caption='Requesting the second page of a collection'><![CDATA[
<iq type='get' id='page2'> <iq type='get' id='page2'>
<retrieve xmlns='urn:xmpp:archive' <retrieve xmlns='urn:xmpp:archive'
@ -1051,7 +1051,7 @@
</set> </set>
</retrieve> </retrieve>
</iq> </iq>
]]></example> ]]></example>
<p>Refer to <cite>Result Set Management</cite> to learn more about the various ways that the pages of a collection may be accessed.</p> <p>Refer to <cite>Result Set Management</cite> to learn more about the various ways that the pages of a collection may be accessed.</p>
</section2> </section2>
<section2 topic='Removing a Collection' anchor='manage-remove'> <section2 topic='Removing a Collection' anchor='manage-remove'>
@ -1062,7 +1062,7 @@
with='juliet@capulet.com/chamber' with='juliet@capulet.com/chamber'
start='1469-07-21T02:56:15Z'/> start='1469-07-21T02:56:15Z'/>
</iq> </iq>
]]></example> ]]></example>
<p>The client MAY remove several collections at once. The 'start' and 'end' elements MAY be specified to indicate a date range. The 'with' attribute MAY specify JID of XMPP entities, see the <link url='#impl-jidmatch'>JID Matching</link> section of this document.</p> <p>The client MAY remove several collections at once. The 'start' and 'end' elements MAY be specified to indicate a date range. The 'with' attribute MAY specify JID of XMPP entities, see the <link url='#impl-jidmatch'>JID Matching</link> section of this document.</p>
<example caption='Removing all collections with a specified bare JID between two times'><![CDATA[ <example caption='Removing all collections with a specified bare JID between two times'><![CDATA[
<iq type='set' id='remove3'> <iq type='set' id='remove3'>
@ -1071,7 +1071,7 @@
start='1469-07-21T02:00:00Z' start='1469-07-21T02:00:00Z'
end='1469-07-21T04:00:00Z'/> end='1469-07-21T04:00:00Z'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the 'with' attribute is omitted then collections with any JID are removed.</p> <p>If the 'with' attribute is omitted then collections with any JID are removed.</p>
<p>If the end date is in the future then all collections on or after the start date are removed.</p> <p>If the end date is in the future then all collections on or after the start date are removed.</p>
<example caption='Removing all collections after a date'><![CDATA[ <example caption='Removing all collections after a date'><![CDATA[
@ -1080,7 +1080,7 @@
start='1469-07-21T02:00:00Z' start='1469-07-21T02:00:00Z'
end='2038-01-01T00:00:00Z'/> end='2038-01-01T00:00:00Z'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the start date is before all the collections in the archive then all collections prior to the end date are removed.</p> <p>If the start date is before all the collections in the archive then all collections prior to the end date are removed.</p>
<example caption='Removing all collections before a date'><![CDATA[ <example caption='Removing all collections before a date'><![CDATA[
<iq type='set' id='remove5'> <iq type='set' id='remove5'>
@ -1088,12 +1088,12 @@
start='0000-01-01T00:00:00Z' start='0000-01-01T00:00:00Z'
end='1469-07-21T04:00:00Z'/> end='1469-07-21T04:00:00Z'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Removing all collections'><![CDATA[ <example caption='Removing all collections'><![CDATA[
<iq type='set' id='remove6'> <iq type='set' id='remove6'>
<remove xmlns='urn:xmpp:archive'/> <remove xmlns='urn:xmpp:archive'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the value of the optional 'open' attribute is set to 'true' then only collections that are currently being recorded automatically by the server (see <link url='#auto'>Automatic Archiving</link>) are removed.</p> <p>If the value of the optional 'open' attribute is set to 'true' then only collections that are currently being recorded automatically by the server (see <link url='#auto'>Automatic Archiving</link>) are removed.</p>
<example caption='Removing a collection being recorded by the server'><![CDATA[ <example caption='Removing a collection being recorded by the server'><![CDATA[
<iq type='set' id='remove7'> <iq type='set' id='remove7'>
@ -1101,13 +1101,13 @@
with='juliet@capulet.com/chamber' with='juliet@capulet.com/chamber'
open='true'/> open='true'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Removing all collections being recorded by the server'><![CDATA[ <example caption='Removing all collections being recorded by the server'><![CDATA[
<iq type='set' id='remove8'> <iq type='set' id='remove8'>
<remove xmlns='urn:xmpp:archive' <remove xmlns='urn:xmpp:archive'
open='true'/> open='true'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the specified collection (or collections) do not exist then the server MUST return an &notfound; error:</p> <p>If the specified collection (or collections) do not exist then the server MUST return an &notfound; error:</p>
<example caption='Unsuccessful reply'><![CDATA[ <example caption='Unsuccessful reply'><![CDATA[
<iq type='error' to='romeo@montague.net/orchard' id='remove1'> <iq type='error' to='romeo@montague.net/orchard' id='remove1'>
@ -1118,7 +1118,7 @@
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -1136,7 +1136,7 @@
</set> </set>
</modified> </modified>
</iq> </iq>
]]></example> ]]></example>
<p>The server MUST return the changed collections in the chronological order that they were changed (most recent last). If a collection has been modified, created, or removed <em>after</em> the time specified by the 'start' attribute, then the server MUST include it in the returned result set page of collections (unless the specified maximum page size would be exceeded). Each &lt;changed/&gt; or &lt;removed/&gt; collection element (for modified/created, or removed collections respectively) in the returned list MUST include the 'with' and 'start' attribues. The XML character data of the &lt;last/&gt; element is a unique, persistent identifier created by the server, which MUST be treated as opaque by the client.</p> <p>The server MUST return the changed collections in the chronological order that they were changed (most recent last). If a collection has been modified, created, or removed <em>after</em> the time specified by the 'start' attribute, then the server MUST include it in the returned result set page of collections (unless the specified maximum page size would be exceeded). Each &lt;changed/&gt; or &lt;removed/&gt; collection element (for modified/created, or removed collections respectively) in the returned list MUST include the 'with' and 'start' attribues. The XML character data of the &lt;last/&gt; element is a unique, persistent identifier created by the server, which MUST be treated as opaque by the client.</p>
<example caption='Receiving a page of modifications'><![CDATA[ <example caption='Receiving a page of modifications'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='sync1'> <iq type='result' to='romeo@montague.net/orchard' id='sync1'>
@ -1154,7 +1154,7 @@
</set> </set>
</modified> </modified>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The server should remember the 'with' and 'start' attribues and the time of removal of all deleted collections. If this "state" cannot be maintained indefinitely, then unless all the user's clients replicate before the server deletes its memory of a removal it will not be reflected in all the local copies of the archive.</p> <p>Note: The server should remember the 'with' and 'start' attribues and the time of removal of all deleted collections. If this "state" cannot be maintained indefinitely, then unless all the user's clients replicate before the server deletes its memory of a removal it will not be reflected in all the local copies of the archive.</p>
<p>Note: Along with its copy of the archive the client SHOULD save the most recent &lt;last/&gt; identifier that it received from the server. The next time it synchronizes with the server it SHOULD specify that identifier when requesting the first result set page by including it as the XML character data of the &lt;after/&gt; element in Result Set Management.</p> <p>Note: Along with its copy of the archive the client SHOULD save the most recent &lt;last/&gt; identifier that it received from the server. The next time it synchronizes with the server it SHOULD specify that identifier when requesting the first result set page by including it as the XML character data of the &lt;after/&gt; element in Result Set Management.</p>
<example caption='Requesting the next page of modifications'><![CDATA[ <example caption='Requesting the next page of modifications'><![CDATA[
@ -1167,7 +1167,7 @@
</set> </set>
</modified> </modified>
</iq> </iq>
]]></example> ]]></example>
<p>After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the master archive. The client should also retrieve from the server the content of each collection that has been modified (see <link url='#retrieve'>Retrieving a Collection</link>) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).</p> <p>After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the master archive. The client should also retrieve from the server the content of each collection that has been modified (see <link url='#retrieve'>Retrieving a Collection</link>) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).</p>
</section1> </section1>
@ -1181,7 +1181,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>For each feature defined herein, if the server supports that feature it MUST return a &lt;feature/&gt; element with the 'var' attribute set to 'urn:xmpp:archive:[name]', where '[name]' is 'auto' for the <link url='#auto'>Automatic Archiving</link> feature, 'manage' for the <link url='#manage'>Archive Management</link> feature, 'manual' for the <link url='#manual'>Manual Archiving</link> feature, and 'pref' for the <link url='#pref'>Archiving Preferences</link> feature.</p> <p>For each feature defined herein, if the server supports that feature it MUST return a &lt;feature/&gt; element with the 'var' attribute set to 'urn:xmpp:archive:[name]', where '[name]' is 'auto' for the <link url='#auto'>Automatic Archiving</link> feature, 'manage' for the <link url='#manage'>Archive Management</link> feature, 'manual' for the <link url='#manual'>Manual Archiving</link> feature, and 'pref' for the <link url='#pref'>Archiving Preferences</link> feature.</p>
<example caption='Server Service Discovery response'> <example caption='Server Service Discovery response'>
<![CDATA[ <![CDATA[
@ -1197,7 +1197,7 @@
<feature var='urn:xmpp:archive:pref'/> <feature var='urn:xmpp:archive:pref'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -1233,13 +1233,13 @@
<feature xmlns='urn:xmpp:archive'> <feature xmlns='urn:xmpp:archive'>
<optional/> <optional/>
</feature> </feature>
]]></example> ]]></example>
<example caption='Stream Feature (Automatic Archiving on By Default)'><![CDATA[ <example caption='Stream Feature (Automatic Archiving on By Default)'><![CDATA[
<feature xmlns='urn:xmpp:archive'> <feature xmlns='urn:xmpp:archive'>
<optional/> <optional/>
<default/> <default/>
</feature> </feature>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
@ -1564,7 +1564,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Alexey Melnikov and Alexander Tsvyashchenko for their comments and suggestions.</p> <p>Thanks to Alexey Melnikov and Alexander Tsvyashchenko for their comments and suggestions.</p>

26
xep-0137.xml
View File

@ -74,7 +74,7 @@
mime-type='mime/type'> mime-type='mime/type'>
<profile xmlns='si-profile'></profile> <profile xmlns='si-profile'></profile>
</sipub> </sipub>
]]></example> ]]></example>
<p>This format is nearly identical to that for the stream initiation &lt;si/&gt; element (see <cite>XEP-0095</cite>). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.</p> <p>This format is nearly identical to that for the stream initiation &lt;si/&gt; element (see <cite>XEP-0095</cite>). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.</p>
<p>The 'from' attribute SHOULD be present, and MUST be present if the stanza containing the &lt;sipub/&gt; is not from the stream owner (e.g., if the stream is advertised at a publish-subscribe node). If present, this attribute MUST be the valid JID for the stream owner.</p> <p>The 'from' attribute SHOULD be present, and MUST be present if the stanza containing the &lt;sipub/&gt; is not from the stream owner (e.g., if the stream is advertised at a publish-subscribe node). If present, this attribute MUST be the valid JID for the stream owner.</p>
<p>The 'id' attribute is an opaque identifier. This attribute MUST be present, and MUST be a valid non-empty string. It uniquely identifies the published request at the potential sender.</p> <p>The 'id' attribute is an opaque identifier. This attribute MUST be present, and MUST be a valid non-empty string. It uniquely identifies the published request at the potential sender.</p>
@ -103,7 +103,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Pubsub service pushes announcement to all subscribers'><![CDATA[ <example caption='Pubsub service pushes announcement to all subscribers'><![CDATA[
<message from='pubsub.shakespeare.lit' to='juliet@capulet.com/balcony'> <message from='pubsub.shakespeare.lit' to='juliet@capulet.com/balcony'>
<event xmlns='http://jabber.org/protocol/pubsub#event'> <event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -125,7 +125,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>The &lt;sipub/&gt; element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &xep0045; or via &xep0033;). This can be especially useful for informing an offline entity about an available stream.</p> <p>The &lt;sipub/&gt; element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &xep0045; or via &xep0033;). This can be especially useful for informing an offline entity about an available stream.</p>
<example caption='Advertising a stream in a message stanza'><![CDATA[ <example caption='Advertising a stream in a message stanza'><![CDATA[
<message from='romeo@montague.net/pda' to='juliet@capulet.com'> <message from='romeo@montague.net/pda' to='juliet@capulet.com'>
@ -141,7 +141,7 @@
</file> </file>
</sipub> </sipub>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Integration with Data Forms' anchor='usecase.xdata'> <section2 topic='Integration with Data Forms' anchor='usecase.xdata'>
<p>One of the goals of sipub is to integrate <cite>Stream Initiation</cite> with <cite>Data Forms</cite> to provide a "file upload" capability. This is accomplished via the datatypes specified in &xep0122;. Each datatype is specific to the profile desired.</p> <p>One of the goals of sipub is to integrate <cite>Stream Initiation</cite> with <cite>Data Forms</cite> to provide a "file upload" capability. This is accomplished via the datatypes specified in &xep0122;. Each datatype is specific to the profile desired.</p>
@ -151,7 +151,7 @@
<validate xmlns='http://jabber.org/protocol/xdata-validate' <validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='sipub:file-transfer'/> datatype='sipub:file-transfer'/>
</field> </field>
]]></example> ]]></example>
<p>When submitting such a form, a field's value(s) MUST be the &lt;sipub/&gt; identifier(s). Also, the submitter MUST provide an &lt;sipub/&gt; element within the data form for each file to be uploaded:</p> <p>When submitting such a form, a field's value(s) MUST be the &lt;sipub/&gt; identifier(s). Also, the submitter MUST provide an &lt;sipub/&gt; element within the data form for each file to be uploaded:</p>
<example caption='Submitting an "Upload File" form'><![CDATA[ <example caption='Submitting an "Upload File" form'><![CDATA[
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -168,7 +168,7 @@
date='2005-07-21T11:21Z'/> date='2005-07-21T11:21Z'/>
</sipub> </sipub>
</x> </x>
]]></example> ]]></example>
<p>The form processor will use this to retrieve the file(s) to be uploaded.</p> <p>The form processor will use this to retrieve the file(s) to be uploaded.</p>
</section2> </section2>
<section2 topic='Triggering the Stream Initiation Request' anchor='usecase.trigger'> <section2 topic='Triggering the Stream Initiation Request' anchor='usecase.trigger'>
@ -181,7 +181,7 @@
<start xmlns='http://jabber.org/protocol/sipub' <start xmlns='http://jabber.org/protocol/sipub'
id='publish-0123'/> id='publish-0123'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the sender accepts the request, it responds with an IQ-result containing a &lt;starting/&gt; element. This element indicates the stream initiation identifier to be used:</p> <p>If the sender accepts the request, it responds with an IQ-result containing a &lt;starting/&gt; element. This element indicates the stream initiation identifier to be used:</p>
<example caption='Sender accepts request to start stream'><![CDATA[ <example caption='Sender accepts request to start stream'><![CDATA[
<iq type='result' <iq type='result'
@ -191,7 +191,7 @@
<starting xmlns='http://jabber.org/protocol/sipub' <starting xmlns='http://jabber.org/protocol/sipub'
sid='session-87651234'/> sid='session-87651234'/>
</iq> </iq>
]]></example> ]]></example>
<p>Then the sender begins the stream initiation negotiation:</p> <p>Then the sender begins the stream initiation negotiation:</p>
<example caption='Sender starts negotiation'><![CDATA[ <example caption='Sender starts negotiation'><![CDATA[
<iq type='set' <iq type='set'
@ -210,7 +210,7 @@
</file> </file>
</si> </si>
</iq> </iq>
]]></example> ]]></example>
<p>If the requested identifier is not valid, the sender SHOULD respond with a &notacceptable; error:</p> <p>If the requested identifier is not valid, the sender SHOULD respond with a &notacceptable; error:</p>
<example caption='Sender denies because of invalid id'><![CDATA[ <example caption='Sender denies because of invalid id'><![CDATA[
<iq type='error' <iq type='error'
@ -222,7 +222,7 @@
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the receiver does not have permission to request the data stream, the sender SHOULD respond with a &forbidden; error:</p> <p>If the receiver does not have permission to request the data stream, the sender SHOULD respond with a &forbidden; error:</p>
<example caption='Sender denies because receiver is forbidden'><![CDATA[ <example caption='Sender denies because receiver is forbidden'><![CDATA[
<iq type='error' <iq type='error'
@ -234,7 +234,7 @@
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl-notes'> <section1 topic='Implementation Notes' anchor='impl-notes'>
@ -261,7 +261,7 @@
<desc>Datatype for publishing an SI using the File Transfer Profile</desc> <desc>Datatype for publishing an SI using the File Transfer Profile</desc>
<doc>XEP-0096</doc> <doc>XEP-0096</doc>
</datatype> </datatype>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -315,6 +315,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

22
xep-0138.xml
View File

@ -106,39 +106,39 @@
<method>lzw</method> <method>lzw</method>
</compression> </compression>
</stream:features> </stream:features>
]]></example> ]]></example>
<p>Note: The &lt;compression/&gt; element MUST contain at least one &lt;method/&gt; child element. Each &lt;method/&gt; element MUST contain XML character data that specifies the name of a compression method, and such method names SHOULD be registered as described in the <link url='#registrar-methods'>Compression Methods Registry</link> section of this document. The methods SHOULD be provided in order of preference.</p> <p>Note: The &lt;compression/&gt; element MUST contain at least one &lt;method/&gt; child element. Each &lt;method/&gt; element MUST contain XML character data that specifies the name of a compression method, and such method names SHOULD be registered as described in the <link url='#registrar-methods'>Compression Methods Registry</link> section of this document. The methods SHOULD be provided in order of preference.</p>
<p>The initiating entity then MAY request compression by specifying one of the methods advertised by the receiving entity:</p> <p>The initiating entity then MAY request compression by specifying one of the methods advertised by the receiving entity:</p>
<example caption='Initiating Entity Requests Stream Compression'><![CDATA[ <example caption='Initiating Entity Requests Stream Compression'><![CDATA[
<compress xmlns='http://jabber.org/protocol/compress'> <compress xmlns='http://jabber.org/protocol/compress'>
<method>zlib</method> <method>zlib</method>
</compress> </compress>
]]></example> ]]></example>
<p>Note: If the initiating entity did not understand any of the advertised compression methods, it SHOULD ignore the compression option and proceed as if no compression methods were advertised.</p> <p>Note: If the initiating entity did not understand any of the advertised compression methods, it SHOULD ignore the compression option and proceed as if no compression methods were advertised.</p>
<p>If the initiating entity requests a stream compression method that is not supported by the receiving entity, the receiving entity MUST return an &lt;unsupported-method/&gt; error:</p> <p>If the initiating entity requests a stream compression method that is not supported by the receiving entity, the receiving entity MUST return an &lt;unsupported-method/&gt; error:</p>
<example caption='Receiving Entity Reports That Method is Unsupported'><![CDATA[ <example caption='Receiving Entity Reports That Method is Unsupported'><![CDATA[
<failure xmlns='http://jabber.org/protocol/compress'> <failure xmlns='http://jabber.org/protocol/compress'>
<unsupported-method/> <unsupported-method/>
</failure> </failure>
]]></example> ]]></example>
<p>If the receiving entity finds the requested method unacceptable or unworkable for any other reason, it MUST return a &lt;setup-failed/&gt; error:</p> <p>If the receiving entity finds the requested method unacceptable or unworkable for any other reason, it MUST return a &lt;setup-failed/&gt; error:</p>
<example caption='Receiving Entity Reports That Negotiation of Stream Compression Failed'><![CDATA[ <example caption='Receiving Entity Reports That Negotiation of Stream Compression Failed'><![CDATA[
<failure xmlns='http://jabber.org/protocol/compress'> <failure xmlns='http://jabber.org/protocol/compress'>
<setup-failed/> <setup-failed/>
</failure> </failure>
]]></example> ]]></example>
<p>Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the compression negotiation if it fails.</p> <p>Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the compression negotiation if it fails.</p>
<p>If no error occurs, the receiving entity MUST inform the initiating entity that compression has been successfully negotiated:</p> <p>If no error occurs, the receiving entity MUST inform the initiating entity that compression has been successfully negotiated:</p>
<example caption='Receiving Entity Acknowledges Negotiation of Stream Compression'><![CDATA[ <example caption='Receiving Entity Acknowledges Negotiation of Stream Compression'><![CDATA[
<compressed xmlns='http://jabber.org/protocol/compress'/> <compressed xmlns='http://jabber.org/protocol/compress'/>
]]></example> ]]></example>
<p>Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in <cite>RFC 3920</cite>) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:</p> <p>Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in <cite>RFC 3920</cite>) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:</p>
<example caption='Initiating Entity Initiates New (Compressed) Stream'><![CDATA[ <example caption='Initiating Entity Initiates New (Compressed) Stream'><![CDATA[
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='shakespeare.lit'> to='shakespeare.lit'>
]]></example> ]]></example>
<p>If compression processing fails after the new (compressed) stream has been established, the entity that detects the error SHOULD generate a stream error and close the stream:</p> <p>If compression processing fails after the new (compressed) stream has been established, the entity that detects the error SHOULD generate a stream error and close the stream:</p>
<example caption='Entity Closes Stream Because of a Processing Error'><![CDATA[ <example caption='Entity Closes Stream Because of a Processing Error'><![CDATA[
<stream:error> <stream:error>
@ -148,7 +148,7 @@
</failure> </failure>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
@ -203,7 +203,7 @@
<desc>a natural-language description of the compression method</desc> <desc>a natural-language description of the compression method</desc>
<doc>the document that specifies or registers the compression method</doc> <doc>the document that specifies or registers the compression method</doc>
</method> </method>
]]></code> ]]></code>
<p>The registrant may register more than one compression method at a time, each contained in a separate &lt;method/&gt; element.</p> <p>The registrant may register more than one compression method at a time, each contained in a separate &lt;method/&gt; element.</p>
</section3> </section3>
<section3 topic='Registration' anchor='registrar-methods-init'> <section3 topic='Registration' anchor='registrar-methods-init'>
@ -213,7 +213,7 @@
<desc>the ZLIB compression method</desc> <desc>the ZLIB compression method</desc>
<doc>RFC 1950</doc> <doc>RFC 1950</doc>
</method> </method>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -245,7 +245,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Protocol Namespace' anchor='schemas-protocol'> <section2 topic='Protocol Namespace' anchor='schemas-protocol'>
<code><![CDATA[ <code><![CDATA[
@ -298,7 +298,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

20
xep-0140.xml
View File

@ -71,13 +71,13 @@
<create node-id='groups/Marketing/Europe'/> <create node-id='groups/Marketing/Europe'/>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Success'><![CDATA[ <example caption='Service Informs Admin of Success'><![CDATA[
<iq type='result' <iq type='result'
from='pubsub.example.com' from='pubsub.example.com'
to='bofh@example.com/daygig' to='bofh@example.com/daygig'
id='create1'/> id='create1'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Adding a Member to the Group' anchor='add'> <section2 topic='Adding a Member to the Group' anchor='add'>
<p>There are two steps to adding a member to a group, which SHOULD be performed in this order:</p> <p>There are two steps to adding a member to a group, which SHOULD be performed in this order:</p>
@ -98,13 +98,13 @@
</entities> </entities>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Success'><![CDATA[ <example caption='Service Informs Admin of Success'><![CDATA[
<iq type='result' <iq type='result'
from='pubsub.example.com' from='pubsub.example.com'
to='bofh@example.com/daygig' to='bofh@example.com/daygig'
id='sub1'/> id='sub1'/>
]]></example> ]]></example>
<p>(Naturally, a member of a shared group need not be informed of changes to the group, and an entity that is informed of changes to the group need not be a member of the group. However, in most applications a group member will be a pubsub subscriber and vice-versa.)</p> <p>(Naturally, a member of a shared group need not be informed of changes to the group, and an entity that is informed of changes to the group need not be a member of the group. However, in most applications a group member will be a pubsub subscriber and vice-versa.)</p>
<p>Now the admin publishes information about the member to the group node.</p> <p>Now the admin publishes information about the member to the group node.</p>
<example caption='Admin Publishes Member Information'><![CDATA[ <example caption='Admin Publishes Member Information'><![CDATA[
@ -124,7 +124,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The member information is then delivered to all subscribers:</p> <p>The member information is then delivered to all subscribers:</p>
<example caption='Member Information is Delivered to All Subscribers'><![CDATA[ <example caption='Member Information is Delivered to All Subscribers'><![CDATA[
<message <message
@ -145,7 +145,7 @@
. .
. .
. .
]]></example> ]]></example>
<p>Note: It is the receiving application's responsibility to add the newly-published roster item to the recipient's roster by following the protocols defined in <strong>XMPP IM</strong>. The receiving application SHOULD NOT prompt the recipient regarding whether or not to add the roster item, but if and only the roster item is received via pubsub (i.e., it SHOULD prompt the user when roster items are received from individual users and not via pubsub).</p> <p>Note: It is the receiving application's responsibility to add the newly-published roster item to the recipient's roster by following the protocols defined in <strong>XMPP IM</strong>. The receiving application SHOULD NOT prompt the recipient regarding whether or not to add the roster item, but if and only the roster item is received via pubsub (i.e., it SHOULD prompt the user when roster items are received from individual users and not via pubsub).</p>
</section2> </section2>
<section2 topic='Removing a Member from the Group' anchor='remove'> <section2 topic='Removing a Member from the Group' anchor='remove'>
@ -167,13 +167,13 @@
</entities> </entities>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service Informs Admin of Success'><![CDATA[ <example caption='Service Informs Admin of Success'><![CDATA[
<iq type='result' <iq type='result'
from='pubsub.example.com' from='pubsub.example.com'
to='bofh@example.com/daygig' to='bofh@example.com/daygig'
id='del1'/> id='del1'/>
]]></example> ]]></example>
<p>(As noted, the group member need not be a pubsub subscriber, in which case the foregoing step may not be necessary.)</p> <p>(As noted, the group member need not be a pubsub subscriber, in which case the foregoing step may not be necessary.)</p>
<p>Now admin can remove the member from the shared group.</p> <p>Now admin can remove the member from the shared group.</p>
<example caption='Admin Removes Member'><![CDATA[ <example caption='Admin Removes Member'><![CDATA[
@ -187,7 +187,7 @@
</retract> </retract>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>All remaining subscribers are then informed that the node has been deleted:</p> <p>All remaining subscribers are then informed that the node has been deleted:</p>
<example caption='Tune Information is Delivered to All Subscribers'><![CDATA[ <example caption='Tune Information is Delivered to All Subscribers'><![CDATA[
<message <message
@ -202,7 +202,7 @@
. .
. .
. .
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Guidelines' anchor='impl'> <section1 topic='Implementation Guidelines' anchor='impl'>

10
xep-0141.xml
View File

@ -94,7 +94,7 @@
<field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'> <field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'>
</field> </field>
</x> </x>
]]></example> ]]></example>
<p>Note: Any newlines in the following examples are provided for the purpose of legibility only.</p> <p>Note: Any newlines in the following examples are provided for the purpose of legibility only.</p>
<section2 topic='Paging Fields' anchor='paging'> <section2 topic='Paging Fields' anchor='paging'>
<p>One of the simplest layout usages is to partition fields into pages. This is done by including one or more &lt;page/&gt; elements within the x:data form. Each &lt;page/&gt; element SHOULD possess a "label" attribute to label the page, MAY contain a &lt;text/&gt; child element for additional information, and SHOULD contain a &lt;fieldref/&gt; element for each field to be included in the page. To reference an x:data field, the &lt;fieldref/&gt; element's "var" attribute MUST be the same as the intended &lt;field/&gt; element's "var" attribute.</p> <p>One of the simplest layout usages is to partition fields into pages. This is done by including one or more &lt;page/&gt; elements within the x:data form. Each &lt;page/&gt; element SHOULD possess a "label" attribute to label the page, MAY contain a &lt;text/&gt; child element for additional information, and SHOULD contain a &lt;fieldref/&gt; element for each field to be included in the page. To reference an x:data field, the &lt;fieldref/&gt; element's "var" attribute MUST be the same as the intended &lt;field/&gt; element's "var" attribute.</p>
@ -158,7 +158,7 @@
<field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'> <field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'>
</field> </field>
</x> </x>
]]></example> ]]></example>
<p>Note: The preceding example partitions the fields into three pages, labeled "Personal Information", "Community Activity", and "Plans and Reasonings".</p> <p>Note: The preceding example partitions the fields into three pages, labeled "Personal Information", "Community Activity", and "Plans and Reasonings".</p>
</section2> </section2>
<section2 topic='Sectioning Fields' anchor='sectioning'> <section2 topic='Sectioning Fields' anchor='sectioning'>
@ -222,7 +222,7 @@
<field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'> <field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'>
</field> </field>
</x> </x>
]]></example> ]]></example>
<p>Note: The preceding example demonstrates a layout similar to the previous example, but using three sections within one page instead of three pages.</p> <p>Note: The preceding example demonstrates a layout similar to the previous example, but using three sections within one page instead of three pages.</p>
<p>As shown in the following example, sections may be nested to produce a more granular partitioning of fields.</p> <p>As shown in the following example, sections may be nested to produce a more granular partitioning of fields.</p>
<example caption='Sections of fields (nested)'><![CDATA[ <example caption='Sections of fields (nested)'><![CDATA[
@ -269,7 +269,7 @@
... ...
</x> </x>
]]></example> ]]></example>
<p>Note: The preceding example partitions the fields into one page and three sections, with the first section being further partitioned into two sub-sections and one free-standing field reference.</p> <p>Note: The preceding example partitions the fields into one page and three sections, with the first section being further partitioned into two sub-sections and one free-standing field reference.</p>
</section2> </section2>
<section2 topic="Including Tables" anchor='tables'> <section2 topic="Including Tables" anchor='tables'>
@ -392,7 +392,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

112
xep-0142.xml
View File

@ -133,7 +133,7 @@
+-----------+ +-----------+
| Chat room | | Chat room |
+-----------+ +-----------+
]]></code> ]]></code>
</section2> </section2>
<section2 topic='User Packet Exchanges' anchor='proto-user'> <section2 topic='User Packet Exchanges' anchor='proto-user'>
<p>Packets are exchanged between the user and service to trigger state changes in the user. These packet exchanges are described next.</p> <p>Packets are exchanged between the user and service to trigger state changes in the user. These packet exchanges are described next.</p>
@ -147,7 +147,7 @@ User Service
| Join Response | | Join Response |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The user sends a join request to the workgroup service in order to join the workgroup queue. <p>The user sends a join request to the workgroup service in order to join the workgroup queue.
The workgroup service may either accept or reject the request. A user session (e.g. user@example.net/home) The workgroup service may either accept or reject the request. A user session (e.g. user@example.net/home)
may have only one active join request. Subsequent, simultaneous joins MUST result in an error.</p> may have only one active join request. Subsequent, simultaneous joins MUST result in an error.</p>
@ -162,12 +162,12 @@ U: <join-queue xmlns='http://jabber.org/protocol/workgroup'>
U: <queue-notifications/> U: <queue-notifications/>
U: </join-queue> U: </join-queue>
U: </iq> U: </iq>
]]></example> ]]></example>
<p>The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the &lt;join-queue&gt; element MAY contain a standard &lt;queue-notifications/&gt; element, which indicates that the user would like to receive user status updates about their state in the queue.</p> <p>The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the &lt;join-queue&gt; element MAY contain a standard &lt;queue-notifications/&gt; element, which indicates that the user would like to receive user status updates about their state in the queue.</p>
<p>A successful join results in a success response:</p> <p>A successful join results in a success response:</p>
<example caption='Response Element'><![CDATA[ <example caption='Response Element'><![CDATA[
S: <iq to='user@example.net/home' from='support@workgroup.example.com' id='id1' type='result'/> S: <iq to='user@example.net/home' from='support@workgroup.example.com' id='id1' type='result'/>
]]></example> ]]></example>
<p>If the user indicated interest in their queue status information, the supported status updates MUST be sent by the server. Compliant implementations do not have to support any status update types. Status updates requested by the user and supported by the server MUST be pushed to the user by the service until the user departs or is invited to a chat room.</p> <p>If the user indicated interest in their queue status information, the supported status updates MUST be sent by the server. Compliant implementations do not have to support any status update types. Status updates requested by the user and supported by the server MUST be pushed to the user by the service until the user departs or is invited to a chat room.</p>
<section4 topic='Error Conditions' anchor='proto-user-join-errors'> <section4 topic='Error Conditions' anchor='proto-user-join-errors'>
<table caption='Join-Queue Error Conditions'> <table caption='Join-Queue Error Conditions'>
@ -212,7 +212,7 @@ S: <iq type='result'
S: from='support@workgroup.example.com' S: from='support@workgroup.example.com'
S: to='user@example.net/home' S: to='user@example.net/home'
S: id='id1'/> S: id='id1'/>
]]></example> ]]></example>
<p>The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the &lt;crm/&gt; element in this example would be defined outside the context of this specification).</p> <p>The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the &lt;crm/&gt; element in this example would be defined outside the context of this specification).</p>
<example caption='Join With Meta-Data'><![CDATA[ <example caption='Join With Meta-Data'><![CDATA[
U: <iq type='set' U: <iq type='set'
@ -234,7 +234,7 @@ S: <iq type='result'
S: from='support@workgroup.example.com' S: from='support@workgroup.example.com'
S: to='user@example.net/home' S: to='user@example.net/home'
S: id='id2'/> S: id='id2'/>
]]></example> ]]></example>
<p>Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see <cite>XEP-0004</cite> for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.</p> <p>Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see <cite>XEP-0004</cite> for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.</p>
<example caption='Join With Form'><![CDATA[ <example caption='Join With Form'><![CDATA[
U: <iq type='set' U: <iq type='set'
@ -253,7 +253,7 @@ S: <error code='406' type='modify'>
S: <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> S: <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
S: </error> S: </error>
S: </iq> S: </iq>
]]></example> ]]></example>
<p>The &e406; error indicates that a data form is required. The user requests the required data form from the workgroup.</p> <p>The &e406; error indicates that a data form is required. The user requests the required data form from the workgroup.</p>
<example caption='Join With Form (2)'><![CDATA[ <example caption='Join With Form (2)'><![CDATA[
U: <iq type='get' U: <iq type='get'
@ -285,7 +285,7 @@ S: </field>
S: </x> S: </x>
S: </join-queue> S: </join-queue>
S: </iq> S: </iq>
]]></example> ]]></example>
<p>After presenting the form to the user and gathering the form data, the user submits the form data to the workgroup and the workgroup accepts it. The user is now in the queue.</p> <p>After presenting the form to the user and gathering the form data, the user submits the form data to the workgroup and the workgroup accepts it. The user is now in the queue.</p>
<example caption='Join With Form (3)'><![CDATA[ <example caption='Join With Form (3)'><![CDATA[
U: <iq type='set' U: <iq type='set'
@ -305,7 +305,7 @@ S: <iq type='result'
S: from='support@workgroup.example.com' S: from='support@workgroup.example.com'
S: to='user@example.net/home' S: to='user@example.net/home'
S: id='id3' /> S: id='id3' />
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='User Depart Protocol' anchor='proto-user-depart'> <section3 topic='User Depart Protocol' anchor='proto-user-depart'>
@ -318,19 +318,19 @@ Requester Service
| Depart Response | | Depart Response |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The service notifies the user that they have been removed from the workgroup queue.</p> <p>The service notifies the user that they have been removed from the workgroup queue.</p>
<example caption='Transactions (2)'><![CDATA[ <example caption='Transactions (2)'><![CDATA[
User Service User Service
| Depart Message | | Depart Message |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<example caption='Depart Request'><![CDATA[ <example caption='Depart Request'><![CDATA[
U: <iq from='user@example.net/home' to='support@workgroup.example.com' id='id1' type='set'> U: <iq from='user@example.net/home' to='support@workgroup.example.com' id='id1' type='set'>
U: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/> U: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/>
U: </iq> U: </iq>
]]></example> ]]></example>
<p>In the typical case, the sender is the user departing the queue. However, it is possible for other users (system administrators for example) to request that another user be removed from the queue. In this case, the jid of the user who is departing is included in the depart request:</p> <p>In the typical case, the sender is the user departing the queue. However, it is possible for other users (system administrators for example) to request that another user be removed from the queue. In this case, the jid of the user who is departing is included in the depart request:</p>
<example caption='Depart Request With JID'><![CDATA[ <example caption='Depart Request With JID'><![CDATA[
U: <iq from='admin-jid' to='support@workgroup.example.com' id='id1' type='set'> U: <iq from='admin-jid' to='support@workgroup.example.com' id='id1' type='set'>
@ -338,18 +338,18 @@ U: <depart-queue xmlns='http://jabber.org/protocol/workgroup'>
U: <jid>user@example.net/home</jid> U: <jid>user@example.net/home</jid>
U: </depart-queue> U: </depart-queue>
U: </iq> U: </iq>
]]></example> ]]></example>
<p>It is expected that implementations will determine who is allowed to remove other users from the queue based on an implementation specific permissions model. These administrator depart requests may result in &e401; errors (see error section). A user removing their own queue entry MUST NOT receive unauthorized errors (the workgroup service MUST NOT prevent a user from departing the queue).</p> <p>It is expected that implementations will determine who is allowed to remove other users from the queue based on an implementation specific permissions model. These administrator depart requests may result in &e401; errors (see error section). A user removing their own queue entry MUST NOT receive unauthorized errors (the workgroup service MUST NOT prevent a user from departing the queue).</p>
<p>The sender of the depart request receives a successful result packet:</p> <p>The sender of the depart request receives a successful result packet:</p>
<example caption='Depart Request'><![CDATA[ <example caption='Depart Request'><![CDATA[
S: <iq from='support@workgroup.example.com' to=user@example.net/home' id='id1' type='result'/> S: <iq from='support@workgroup.example.com' to=user@example.net/home' id='id1' type='result'/>
]]></example> ]]></example>
<p>And the user who is departing receives a depart message (the user may not have been the sender of the request):</p> <p>And the user who is departing receives a depart message (the user may not have been the sender of the request):</p>
<example caption='Depart Message'><![CDATA[ <example caption='Depart Message'><![CDATA[
S: <message from='support@workgroup.example.com' to='user@example.net/home'> S: <message from='support@workgroup.example.com' to='user@example.net/home'>
S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/> S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/>
S: </message> S: </message>
]]></example> ]]></example>
<p>The user will not be in the queue after a response is received unless the error response code is &e401;.</p> <p>The user will not be in the queue after a response is received unless the error response code is &e401;.</p>
<section4 topic='Error Conditions' anchor='proto-user-depart-errors'> <section4 topic='Error Conditions' anchor='proto-user-depart-errors'>
<table caption='Depart-Queue Error Conditions'> <table caption='Depart-Queue Error Conditions'>
@ -383,7 +383,7 @@ S: type='result'/>
S: <message from='support@workgroup.example.com' to='user@example.net/home'> S: <message from='support@workgroup.example.com' to='user@example.net/home'>
S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/> S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/>
S: </message> S: </message>
]]></example> ]]></example>
<p>An administrator removes a user from the workgroup queue support@workgroup.example.com. <p>An administrator removes a user from the workgroup queue support@workgroup.example.com.
Notice that the depart-queue message is sent to the user that has left the queue.</p> Notice that the depart-queue message is sent to the user that has left the queue.</p>
<example caption='Administrator Removes User'><![CDATA[ <example caption='Administrator Removes User'><![CDATA[
@ -402,7 +402,7 @@ S: type='result'/>
S: <message from='support@workgroupexample.com' to='user@example.net/home'> S: <message from='support@workgroupexample.com' to='user@example.net/home'>
S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/> S: <depart-queue xmlns='http://jabber.org/protocol/workgroup'/>
S: </message> S: </message>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='User Status Update Protocol' anchor='proto-user-status'> <section3 topic='User Status Update Protocol' anchor='proto-user-status'>
@ -418,7 +418,7 @@ User Service
| User Status Response | | User Status Response |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The workgroup service pushes updates to the user as their queue status changes. Furthermore, the user may request their queue status at any time.</p> <p>The workgroup service pushes updates to the user as their queue status changes. Furthermore, the user may request their queue status at any time.</p>
<section4 topic='User Status Updates' anchor='proto-user-status-updates'> <section4 topic='User Status Updates' anchor='proto-user-status-updates'>
<p>User status updates are contained in a &lt;queue-status/&gt; element that updates the user on their queue position and estimated time. The position contained in a &lt;position&gt; sub-element is a non-negative integer indicating the number of queue entries that must be routed to an agent before the user is routed to an agent. A position of 0 (zero) indicates the user is currently being routed. Clients may use this information to display the current queue position to the user.</p> <p>User status updates are contained in a &lt;queue-status/&gt; element that updates the user on their queue position and estimated time. The position contained in a &lt;position&gt; sub-element is a non-negative integer indicating the number of queue entries that must be routed to an agent before the user is routed to an agent. A position of 0 (zero) indicates the user is currently being routed. Clients may use this information to display the current queue position to the user.</p>
@ -431,7 +431,7 @@ S: <position>4</position>
S: <time>60</time> S: <time>60</time>
S: </queue-status> S: </queue-status>
S: </message> S: </message>
]]></example> ]]></example>
<p>Alternately the client may poll their position:</p> <p>Alternately the client may poll their position:</p>
<example caption='User Status Poll'><![CDATA[ <example caption='User Status Poll'><![CDATA[
U: <iq to='support@workgroup.example.com' from='user@example.net/home' id='id1' type='get'> U: <iq to='support@workgroup.example.com' from='user@example.net/home' id='id1' type='get'>
@ -443,7 +443,7 @@ S: <position>4</position>
S: <time>60</time> S: <time>60</time>
S: </queue-status> S: </queue-status>
S: </iq> S: </iq>
]]></example> ]]></example>
</section4> </section4>
<section4 topic='Error Conditions' anchor='proto-user-status-errors'> <section4 topic='Error Conditions' anchor='proto-user-status-errors'>
<table caption='Queue-Status Error Conditions'> <table caption='Queue-Status Error Conditions'>
@ -470,7 +470,7 @@ User Service
| User Invite | | User Invite |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the &lt;invite/&gt; element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.</p> <p>The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the &lt;invite/&gt; element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.</p>
<section4 topic='Error Conditions' anchor='proto-user-invite-errors'> <section4 topic='Error Conditions' anchor='proto-user-invite-errors'>
<p>There are no defined error conditions for user invitations.</p> <p>There are no defined error conditions for user invitations.</p>
@ -490,7 +490,7 @@ S: </reason>
S: </invite> S: </invite>
S: </x> S: </x>
S: </message> S: </message>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
</section2> </section2>
@ -507,7 +507,7 @@ S: </message>
| | |Agent | | | |Agent |
| Status | |Presence | | Status | |Presence |
+--------+ +---------+ +--------+ +---------+
]]></code> ]]></code>
<p>Once an agent has joined a workgroup and is available, the agent will receive offers to chat with users by the workgroup service. Chat offers will be made to the agent and the agent has the opportunity to accept or reject each offer. The workgroup service may also revoke an offer. For example, a service may revoke chat offers if the offer is not responded to within a certain period of time to ensure fast responses to user chat requests.</p> <p>Once an agent has joined a workgroup and is available, the agent will receive offers to chat with users by the workgroup service. Chat offers will be made to the agent and the agent has the opportunity to accept or reject each offer. The workgroup service may also revoke an offer. For example, a service may revoke chat offers if the offer is not responded to within a certain period of time to ensure fast responses to user chat requests.</p>
<p>Once an offer has been accepted, the agent must wait for a standard groupchat invitation from the workgroup service. The workgroup service may revoke the offer at this stage of the protocol as well. This enables workgroup services to send offers to several agents in parallel, and choose the 'best' agent that accepts. A diagram showing the agent workgroup sub-states and transitions is shown below:</p> <p>Once an offer has been accepted, the agent must wait for a standard groupchat invitation from the workgroup service. The workgroup service may revoke the offer at this stage of the protocol as well. This enables workgroup services to send offers to several agents in parallel, and choose the 'best' agent that accepts. A diagram showing the agent workgroup sub-states and transitions is shown below:</p>
<code><![CDATA[ <code><![CDATA[
@ -534,7 +534,7 @@ S: </message>
+-----------+ +-----------+
| Chat room | | Chat room |
+-----------+ +-----------+
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Agent Packet Exchanges' anchor='proto-agent'> <section2 topic='Agent Packet Exchanges' anchor='proto-agent'>
<p>Packets are exchanged between the agent and service to trigger state changes in the agent client. These packet exchanges are described next.</p> <p>Packets are exchanged between the agent and service to trigger state changes in the agent client. These packet exchanges are described next.</p>
@ -545,7 +545,7 @@ Agent Service
| Presence Update | | Presence Update |
|----------------------------->| |----------------------------->|
| | | |
]]></example> ]]></example>
<p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p> <p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p>
<example caption='Presence Update'><![CDATA[ <example caption='Presence Update'><![CDATA[
U: <presence from='alice@example.com/work' to='support@workgroup.example.com'> U: <presence from='alice@example.com/work' to='support@workgroup.example.com'>
@ -553,7 +553,7 @@ U: <agent-status xmlns='http://jabber.org/protocol/workgroup'>
U: <max-chats>count</max-chats> U: <max-chats>count</max-chats>
U: </agent-status> U: </agent-status>
U: </presence> U: </presence>
]]></example> ]]></example>
<p>Agent presence updates use standard XMPP presence packets and should contain the normal sub elements as needed (e.g. &SHOW;, &STATUS;, etc) and can be of type='unavailable' to indicate the agent is not available for workgroup routing or for receiving workgroup agent updates. The standard XMPP show states have specific meaning within the context of the workgroup protocol:</p> <p>Agent presence updates use standard XMPP presence packets and should contain the normal sub elements as needed (e.g. &SHOW;, &STATUS;, etc) and can be of type='unavailable' to indicate the agent is not available for workgroup routing or for receiving workgroup agent updates. The standard XMPP show states have specific meaning within the context of the workgroup protocol:</p>
<ul> <ul>
<li>chat - Indicates the agent is available to chat (is idle and ready to handle more conversations).</li> <li>chat - Indicates the agent is available to chat (is idle and ready to handle more conversations).</li>
@ -575,7 +575,7 @@ U: <agent-status xmlns='http://jabber.org/protocol/workgroup'>
U: <max-chats>3</max-chats> U: <max-chats>3</max-chats>
U: </agent-status> U: </agent-status>
U: </presence> U: </presence>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Workgroup Status Update Protocol' anchor='proto-workgroup-status'> <section3 topic='Workgroup Status Update Protocol' anchor='proto-workgroup-status'>
@ -589,7 +589,7 @@ S: <current-chats>count</current-chats>
S: <max-chats>count</max-chats> S: <max-chats>count</max-chats>
S: </notify-agents> S: </notify-agents>
S: </presence> S: </presence>
]]></example> ]]></example>
<p>The defined sub-elements of &lt;notify-agents&gt; are:</p> <p>The defined sub-elements of &lt;notify-agents&gt; are:</p>
<ul> <ul>
@ -610,7 +610,7 @@ S: <current-chats>2</current-chats>
S: <max-chats>7</max-chats> S: <max-chats>7</max-chats>
S: </notify-agents> S: </notify-agents>
S: </presence> S: </presence>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Queue Status Update Protocol' anchor='proto-queue-status'> <section3 topic='Queue Status Update Protocol' anchor='proto-queue-status'>
@ -626,7 +626,7 @@ S: <time>average-time-to-chat</time>
S: <status>open</status> S: <status>open</status>
S: </notify-queue> S: </notify-queue>
S: </presence> S: </presence>
]]></example> ]]></example>
<p>The defined sub-elements of &lt;notify-queue&gt; are:</p> <p>The defined sub-elements of &lt;notify-queue&gt; are:</p>
<ul> <ul>
<li>&lt;count&gt; - The total number of users in the workgroup queue.</li> <li>&lt;count&gt; - The total number of users in the workgroup queue.</li>
@ -652,7 +652,7 @@ S: <join-time>YYYY-MM-DDTHH:mm:SS</join-time>
S: </user> S: </user>
S: </notify-queue-details> S: </notify-queue-details>
S: </presence> S: </presence>
]]></example> ]]></example>
<p>An update may contain one or more &lt;user&gt; entries (one per user in the queue). The defined sub-elements of &lt;user&gt; are:</p> <p>An update may contain one or more &lt;user&gt; entries (one per user in the queue). The defined sub-elements of &lt;user&gt; are:</p>
<ul> <ul>
<li>&lt;position&gt; - The user's zero-based position in the queue.</li> <li>&lt;position&gt; - The user's zero-based position in the queue.</li>
@ -682,7 +682,7 @@ S: <join-time>20050208T10:00:00</join-time>
S: </user> S: </user>
S: </notify-queue-details> S: </notify-queue-details>
S: </presence> S: </presence>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Agent Status Update Protocol' anchor='proto-agent-status'> <section3 topic='Agent Status Update Protocol' anchor='proto-agent-status'>
@ -696,7 +696,7 @@ Agent Service
| | | |
| Agent Presence Pushes | | Agent Presence Pushes |
|<-----------------------------| |<-----------------------------|
]]></example> ]]></example>
<p>The workgroup service pushes presence updates to the agent as the presence of other agents changes. This will only occur after an agent has requested to receive other agents' information. The server will continue to send presence updates until the agent sends an unavailable presence to the server. This protocol is similar to the standard XMPP roster workflow.</p> <p>The workgroup service pushes presence updates to the agent as the presence of other agents changes. This will only occur after an agent has requested to receive other agents' information. The server will continue to send presence updates until the agent sends an unavailable presence to the server. This protocol is similar to the standard XMPP roster workflow.</p>
<p>To receive presence updates for other agents in the workgroup, the agent sends an agent info request to the workgroup:</p> <p>To receive presence updates for other agents in the workgroup, the agent sends an agent info request to the workgroup:</p>
<example caption='Request Element'><![CDATA[ <example caption='Request Element'><![CDATA[
@ -704,7 +704,7 @@ U: <iq to='support@workgroup.example.com' from='alice@example.com/work'
U: id='id1' type='get'> U: id='id1' type='get'>
U: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'/> U: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'/>
U: </iq> U: </iq>
]]></example> ]]></example>
<p>The workgroup will then reply with a list of all agents in the workgroup (excluding the agent making the request):</p> <p>The workgroup will then reply with a list of all agents in the workgroup (excluding the agent making the request):</p>
<example caption='Response Element'><![CDATA[ <example caption='Response Element'><![CDATA[
S: <iq to='alice@example.com/work' from='support@workgroup.example.com' S: <iq to='alice@example.com/work' from='support@workgroup.example.com'
@ -713,7 +713,7 @@ S: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'>
S: <agent jid='bob@example.com' /> S: <agent jid='bob@example.com' />
S: </agent-status-request> S: </agent-status-request>
S: </iq> S: </iq>
]]></example> ]]></example>
<p>The server will then push presence packets for other agents as their presence changes. All fields in the &lt;agent-status&gt; child stanza are optional, but an &lt;agent-status&gt; child stanza must be present:</p> <p>The server will then push presence packets for other agents as their presence changes. All fields in the &lt;agent-status&gt; child stanza are optional, but an &lt;agent-status&gt; child stanza must be present:</p>
<example caption='Agent Status Update'><![CDATA[ <example caption='Agent Status Update'><![CDATA[
S: <presence to='alice@example.com/work' from='bob@example.com/work'> S: <presence to='alice@example.com/work' from='bob@example.com/work'>
@ -722,7 +722,7 @@ S: <current-chats>2</current-chats>
S: <max-chats>4</max-chats> S: <max-chats>4</max-chats>
S: </agent-status> S: </agent-status>
S: </presence> S: </presence>
]]></example> ]]></example>
<p>The defined sub-elements of &lt;agent-status&gt; are:</p> <p>The defined sub-elements of &lt;agent-status&gt; are:</p>
<ul> <ul>
<li>&lt;current-chats&gt; - The number of conversations currently being handled by the agent.</li> <li>&lt;current-chats&gt; - The number of conversations currently being handled by the agent.</li>
@ -741,7 +741,7 @@ Agent Service
| Offer Response | | Offer Response |
|----------------------------->| |----------------------------->|
| | | |
]]></example> ]]></example>
<p>The agent is offered a chat with a user. A successful offer results in the agent owning the offer, but does not mean it has accepted the chat. Accepting an offer is handled by the Agent Accept protocol. The separation between offer and acceptance is made so that agents may receive offers while engaged in other activities (busy with other chats) and accept them at a later time.</p> <p>The agent is offered a chat with a user. A successful offer results in the agent owning the offer, but does not mean it has accepted the chat. Accepting an offer is handled by the Agent Accept protocol. The separation between offer and acceptance is made so that agents may receive offers while engaged in other activities (busy with other chats) and accept them at a later time.</p>
<example caption='Offer Request'><![CDATA[ <example caption='Offer Request'><![CDATA[
S: <iq from='support@workgroup.example.com' to='alice@example.com/work' id='id1' type='set'> S: <iq from='support@workgroup.example.com' to='alice@example.com/work' id='id1' type='set'>
@ -749,11 +749,11 @@ S: <offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/h
S: <timeout>seconds</timeout> S: <timeout>seconds</timeout>
S: </offer> S: </offer>
S: </iq> S: </iq>
]]></example> ]]></example>
<p>Application specific meta-data will normally be added as a sub-element of &lt;offer&gt; to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional &lt;timeout&gt; sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p> <p>Application specific meta-data will normally be added as a sub-element of &lt;offer&gt; to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional &lt;timeout&gt; sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p>
<example caption='Offer Response'><![CDATA[ <example caption='Offer Response'><![CDATA[
A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/> A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/>
]]></example> ]]></example>
<p>The agent may respond only with a successful result.</p> <p>The agent may respond only with a successful result.</p>
<section4 topic='Error Conditions' anchor='proto-agent-offer-errors'> <section4 topic='Error Conditions' anchor='proto-agent-offer-errors'>
<p>There are no defined error conditions for an offer response.</p> <p>There are no defined error conditions for an offer response.</p>
@ -772,7 +772,7 @@ A: <iq to='support@workgroup.example.com'
A: from='alice@example.com/work' A: from='alice@example.com/work'
A: id='id1' A: id='id1'
A: type='result'/> A: type='result'/>
]]></example> ]]></example>
<p>The following is a more typical offer containing meta-data about the user. The offer will be revoked in 30 seconds.</p> <p>The following is a more typical offer containing meta-data about the user. The offer will be revoked in 30 seconds.</p>
<example caption='Offer Including Meta-Data'><![CDATA[ <example caption='Offer Including Meta-Data'><![CDATA[
S: <iq to='alice@example.com/work' S: <iq to='alice@example.com/work'
@ -791,7 +791,7 @@ A: <iq to='support@workgroup.example.com'
A: from='alice@example.com/work' A: from='alice@example.com/work'
A: id='id2' A: id='id2'
A: type='result'/> A: type='result'/>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Agent Offer Accept/Reject Protocol' anchor='proto-agent-acceptreject'> <section3 topic='Agent Offer Accept/Reject Protocol' anchor='proto-agent-acceptreject'>
@ -803,21 +803,21 @@ Agent Service
| Offer Accept/Reject Response | | Offer Accept/Reject Response |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The agent accepts or rejects an offer to chat with a user.</p> <p>The agent accepts or rejects an offer to chat with a user.</p>
<example caption='Offer Accept Request'><![CDATA[ <example caption='Offer Accept Request'><![CDATA[
A: <iq to='support@workgroup.example.com' from='alice@example.com/work' id='id1' type='set'> A: <iq to='support@workgroup.example.com' from='alice@example.com/work' id='id1' type='set'>
A: <offer-accept jid='user@example.net/home' xmlns='http://jabber.org/protocol/workgroup' /> A: <offer-accept jid='user@example.net/home' xmlns='http://jabber.org/protocol/workgroup' />
A: </iq> A: </iq>
]]></example> ]]></example>
<example caption='Offer Reject Request'><![CDATA[ <example caption='Offer Reject Request'><![CDATA[
A: <iq to='support@workgroup.example.com' from='alice@example.com/work' id='id1' type='set'> A: <iq to='support@workgroup.example.com' from='alice@example.com/work' id='id1' type='set'>
A: <offer-reject jid='user@example.net/home' xmlns='http://jabber.org/protocol/workgroup'/> A: <offer-reject jid='user@example.net/home' xmlns='http://jabber.org/protocol/workgroup'/>
A: </iq> A: </iq>
]]></example> ]]></example>
<example caption='Offer Response'><![CDATA[ <example caption='Offer Response'><![CDATA[
S: <iq to='alice@example.com/work' from='support@workgroup.example.com' id='id1' type='result'/> S: <iq to='alice@example.com/work' from='support@workgroup.example.com' id='id1' type='result'/>
]]></example> ]]></example>
<p>The service may respond only with a successful result.</p> <p>The service may respond only with a successful result.</p>
<section4 topic='Error Conditions' anchor='proto-agent-acceptreject-errors'> <section4 topic='Error Conditions' anchor='proto-agent-acceptreject-errors'>
<p>There are no defined error conditions for an accept/reject offer response.</p> <p>There are no defined error conditions for an accept/reject offer response.</p>
@ -834,7 +834,7 @@ S: <iq from='support@workgroup.example.com'
S: to='alice@example.com/work' S: to='alice@example.com/work'
S: id='id3' S: id='id3'
S: type='result'/> S: type='result'/>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Agent Offer Revoke Protocol' anchor='proto-agent-revoke'> <section3 topic='Agent Offer Revoke Protocol' anchor='proto-agent-revoke'>
@ -846,7 +846,7 @@ Agent Service
| Offer Revoke Response | | Offer Revoke Response |
|----------------------------->| |----------------------------->|
| | | |
]]></example> ]]></example>
<p>The service revokes an earlier offer to chat to a user. Offer revocations typically occur when the original offer times out, or a better agent was found to handle the chat. Note that offer revocations may occur anytime after an offer has been made, and before an invitation is sent (see agent state diagram). In other words, even though an agent has accepted an offer to chat, the agent may still receive an offer revocation (e.g. a better agent was found to handle the chat).</p> <p>The service revokes an earlier offer to chat to a user. Offer revocations typically occur when the original offer times out, or a better agent was found to handle the chat. Note that offer revocations may occur anytime after an offer has been made, and before an invitation is sent (see agent state diagram). In other words, even though an agent has accepted an offer to chat, the agent may still receive an offer revocation (e.g. a better agent was found to handle the chat).</p>
<example caption='Offer Revoke Request'><![CDATA[ <example caption='Offer Revoke Request'><![CDATA[
S: <iq from='support@workgroup.example.com' to='alice@example.com/work' id='id1' type='set'> S: <iq from='support@workgroup.example.com' to='alice@example.com/work' id='id1' type='set'>
@ -856,11 +856,11 @@ S: [natural-language text]
S: </reason> S: </reason>
S: </offer-revoke> S: </offer-revoke>
S: </iq> S: </iq>
]]></example> ]]></example>
<p>The reason element may optionally contain free form text explaining the reason the offer was revoked.</p> <p>The reason element may optionally contain free form text explaining the reason the offer was revoked.</p>
<example caption='Offer Response'><![CDATA[ <example caption='Offer Response'><![CDATA[
A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/> A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/>
]]></example> ]]></example>
<p>The agent may respond only with a successful result.</p> <p>The agent may respond only with a successful result.</p>
<section4 topic='Error Conditions' anchor='proto-agent-revoke-errors'> <section4 topic='Error Conditions' anchor='proto-agent-revoke-errors'>
<p>There are no defined error conditions for an offer response.</p> <p>There are no defined error conditions for an offer response.</p>
@ -881,7 +881,7 @@ A: <iq to='support@workgroup.example.com'
A: from='alice@example.com/work' A: from='alice@example.com/work'
A: id='id4' A: id='id4'
A: type='result'/> A: type='result'/>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
<section3 topic='Agent Invite Protocol' anchor='proto-agent-invite'> <section3 topic='Agent Invite Protocol' anchor='proto-agent-invite'>
@ -891,12 +891,12 @@ Agent Service
| Agent Invite | | Agent Invite |
|<-----------------------------| |<-----------------------------|
| | | |
]]></example> ]]></example>
<p>The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the &lt;invite/&gt; element MUST be set to the JID of the workgroup.</p> <p>The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the &lt;invite/&gt; element MUST be set to the JID of the workgroup.</p>
<p>In order to match invitations to offers, all invitations SHOULD include meta-data in the &lt;offer/&gt; element, with the JID of the user specified via the 'jid' attribute. The typical meta-data fragment would appear as:</p> <p>In order to match invitations to offers, all invitations SHOULD include meta-data in the &lt;offer/&gt; element, with the JID of the user specified via the 'jid' attribute. The typical meta-data fragment would appear as:</p>
<example caption='Invitation Meta-Data'><![CDATA[ <example caption='Invitation Meta-Data'><![CDATA[
<offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'> <offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'>
]]></example> ]]></example>
<section4 topic='Error Conditions' anchor='proto-agent-invite-errors'> <section4 topic='Error Conditions' anchor='proto-agent-invite-errors'>
<p>There are no defined error conditions for agent invitations.</p> <p>There are no defined error conditions for agent invitations.</p>
</section4> </section4>
@ -915,7 +915,7 @@ S: </invite>
S: </x> S: </x>
S: <offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'/> S: <offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'/>
S: </message> S: </message>
]]></example> ]]></example>
</section4> </section4>
</section3> </section3>
</section2> </section2>
@ -979,7 +979,7 @@ S: </field>
S: </x> S: </x>
S: </query> S: </query>
S: </iq> S: </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<ul> <ul>
@ -1011,7 +1011,7 @@ S: </iq>
<doc>XEP-0142</doc> <doc>XEP-0142</doc>
</type> </type>
</category> </category>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
@ -1197,7 +1197,7 @@ S: </iq>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'> <section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>The author would like to thank Iain Shigeoka for his work on the first version of this document, and Derek DeMoro and Gaston Dombiak for their comments.</p> <p>The author would like to thank Iain Shigeoka for his work on the first version of this document, and Derek DeMoro and Gaston Dombiak for their comments.</p>

4
xep-0143.xml
View File

@ -186,7 +186,7 @@
type='chat'> type='chat'>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Error Codes' anchor='sections-errors'> <section2 topic='Error Codes' anchor='sections-errors'>
<p>If your proposal defines a number of error and status codes (as is done in <cite>XEP-0045</cite>), it is a good idea to include a table of all the codes defined in your document.</p> <p>If your proposal defines a number of error and status codes (as is done in <cite>XEP-0045</cite>), it is a good idea to include a table of all the codes defined in your document.</p>
@ -251,7 +251,7 @@
</field> </field>
</query> </query>
</iq> </iq>
]]></code> ]]></code>
<p>Some examples include strings that are the output of a hashing algorithm such as SHA-1 (see &rfc3174;) or SHA-256 (see &xep0300;). An easy way to generate these is to use the <link url='http://www.openssl.org/'>OpenSSL</link> "dgst" command to generate the hash. For example, the following command will generate the SHA-1 hash "9f5f9fdab9da7fc12e3c52b258acbcb4bb8e66ac":</p> <p>Some examples include strings that are the output of a hashing algorithm such as SHA-1 (see &rfc3174;) or SHA-256 (see &xep0300;). An easy way to generate these is to use the <link url='http://www.openssl.org/'>OpenSSL</link> "dgst" command to generate the hash. For example, the following command will generate the SHA-1 hash "9f5f9fdab9da7fc12e3c52b258acbcb4bb8e66ac":</p>
<code> <code>
echo -n 'bard@shakespeare.lit' | openssl dgst -hex -sha1 echo -n 'bard@shakespeare.lit' | openssl dgst -hex -sha1

12
xep-0144.xml
View File

@ -120,7 +120,7 @@
</item> </item>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>In determining how to handle any given roster item whose 'action' attribute has a value of "add" (either explicitly or as the default value), the receiving application SHOULD proceed as follows:</p> <p>In determining how to handle any given roster item whose 'action' attribute has a value of "add" (either explicitly or as the default value), the receiving application SHOULD proceed as follows:</p>
<ol> <ol>
<li>If the item already exists in the roster and the item is in the specified group (or no group is specified), the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.</li> <li>If the item already exists in the roster and the item is in the specified group (or no group is specified), the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.</li>
@ -147,7 +147,7 @@
</item> </item>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>In determining how to handle any given roster item whose 'action' attribute has a value of "delete", the receiving application SHOULD proceed as follows:</p> <p>In determining how to handle any given roster item whose 'action' attribute has a value of "delete", the receiving application SHOULD proceed as follows:</p>
<ol> <ol>
<li>If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT delete that item from the roster.</li> <li>If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT delete that item from the roster.</li>
@ -173,7 +173,7 @@
</item> </item>
</x> </x>
</message> </message>
]]></example> ]]></example>
<p>In determining how to handle any given roster item whose 'action' attribute has a value of "modify", the receiving application SHOULD proceed as follows:</p> <p>In determining how to handle any given roster item whose 'action' attribute has a value of "modify", the receiving application SHOULD proceed as follows:</p>
<ol> <ol>
<li>If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.</li> <li>If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.</li>
@ -193,7 +193,7 @@
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<p>The receiving entity then indicates its support:</p> <p>The receiving entity then indicates its support:</p>
<example caption='Receiving Entity Advertises Support'><![CDATA[ <example caption='Receiving Entity Advertises Support'><![CDATA[
<iq from='hamlet@denmark.lit/throne' <iq from='hamlet@denmark.lit/throne'
@ -206,7 +206,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Stanza Types' anchor='stanza'> <section1 topic='Stanza Types' anchor='stanza'>
<p>Roster item exchanges can be sent in any of the four following ways:</p> <p>Roster item exchanges can be sent in any of the four following ways:</p>
@ -315,7 +315,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

2
xep-0145.xml
View File

@ -169,7 +169,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

18
xep-0146.xml
View File

@ -120,7 +120,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/rc#set-status'/> node='http://jabber.org/protocol/rc#set-status'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service <link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p> SHOULD return the appropriate form.</p>
@ -179,7 +179,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Local Client Submits Set Status Form to Remote Client'><![CDATA[ <example caption='Local Client Submits Set Status Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
@ -205,7 +205,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>If the 'status-priority' variable is omitted, the client SHOULD NOT <p>If the 'status-priority' variable is omitted, the client SHOULD NOT
change the priority of the client</p> change the priority of the client</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[ <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
@ -219,7 +219,7 @@
sessionid='set-status:20040727T0337Z' sessionid='set-status:20040727T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
<p>Notification of completion MAY include the processed data in a data <p>Notification of completion MAY include the processed data in a data
form of type 'result'.</p> form of type 'result'.</p>
</section2> </section2>
@ -516,7 +516,7 @@
action='execute' action='execute'
node='http://jabber.org/protocol/rc#leave-groupchats'/> node='http://jabber.org/protocol/rc#leave-groupchats'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Remote Client Replies with a Form with a List of Groupchats it is currently in'><![CDATA[ <example caption='Remote Client Replies with a Form with a List of Groupchats it is currently in'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
@ -550,7 +550,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<example caption='Local Client Submits Form to Remote Client'><![CDATA[ <example caption='Local Client Submits Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
@ -571,7 +571,7 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The remote client leaves the requested groupchats, and informs the <p>The remote client leaves the requested groupchats, and informs the
local client of completion.</p> local client of completion.</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[ <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
@ -585,7 +585,7 @@
sessionid='leave-groupchats:20040727T0337Z' sessionid='leave-groupchats:20040727T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -726,7 +726,7 @@
type='text-single' type='text-single'
label='The new priority for the client'/> label='The new priority for the client'/>
</form_type> </form_type>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>

34
xep-0147.xml
View File

@ -120,7 +120,7 @@
<p>It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).</p> <p>It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).</p>
<example caption='Basic Message Action'><![CDATA[ <example caption='Basic Message Action'><![CDATA[
xmpp:romeo@montague.net?message xmpp:romeo@montague.net?message
]]></example> ]]></example>
<p>A query component whose querytype is "message" MAY specify various key-value pairs. The following three keys are associated with the child elements of the &MESSAGE; stanza specified in the XML schema for the 'jabber:client' namespace as defined in &xmppim;:</p> <p>A query component whose querytype is "message" MAY specify various key-value pairs. The following three keys are associated with the child elements of the &MESSAGE; stanza specified in the XML schema for the 'jabber:client' namespace as defined in &xmppim;:</p>
<ol> <ol>
<li>subject</li> <li>subject</li>
@ -136,13 +136,13 @@ xmpp:romeo@montague.net?message
<p>Other keys MAY be registered with the XMPP Registrar but are not specified herein.</p> <p>Other keys MAY be registered with the XMPP Registrar but are not specified herein.</p>
<example caption='Message Action with Keys: IRI/URI'><![CDATA[ <example caption='Message Action with Keys: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?message;subject=Test%20Message;body=Here%27s%20a%20test%20message xmpp:romeo@montague.net?message;subject=Test%20Message;body=Here%27s%20a%20test%20message
]]></example> ]]></example>
<example caption='Message Action with Keys: Resulting Stanza'><![CDATA[ <example caption='Message Action with Keys: Resulting Stanza'><![CDATA[
<message to='romeo@montague.net'> <message to='romeo@montague.net'>
<subject>Test Message</subject> <subject>Test Message</subject>
<body>Here&apos;s a test message.</body> <body>Here&apos;s a test message.</body>
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Roster Management Actions' anchor='actions-roster'> <section2 topic='Roster Management Actions' anchor='actions-roster'>
<p>The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in <cite>RFC 3921</cite>. The following actions are defined.</p> <p>The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in <cite>RFC 3921</cite>. The following actions are defined.</p>
@ -150,27 +150,27 @@ xmpp:romeo@montague.net?message;subject=Test%20Message;body=Here%27s%20a%20test%
<p>The registered querytype for adding items to the roster or editing items in the roster is "roster" (effectively there is no difference between adding and editing). An XMPP IRI/URI containing a "roster" querytype MAY also include at most one "name" key whose value maps to the 'name' attribute of the &lt;item/&gt; element within the 'jabber:iq:roster' namespace, and MAY contain one "group" key whose value maps to the character data of the &lt;group/&gt; child element of &lt;item/&gt;.</p> <p>The registered querytype for adding items to the roster or editing items in the roster is "roster" (effectively there is no difference between adding and editing). An XMPP IRI/URI containing a "roster" querytype MAY also include at most one "name" key whose value maps to the 'name' attribute of the &lt;item/&gt; element within the 'jabber:iq:roster' namespace, and MAY contain one "group" key whose value maps to the character data of the &lt;group/&gt; child element of &lt;item/&gt;.</p>
<example caption='Roster Action: IRI/URI'><![CDATA[ <example caption='Roster Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?roster xmpp:romeo@montague.net?roster
]]></example> ]]></example>
<example caption='Roster Action: Resulting Stanza'><![CDATA[ <example caption='Roster Action: Resulting Stanza'><![CDATA[
<iq type='set'> <iq type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net'/> <item jid='romeo@montague.net'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Roster Action With Name: IRI/URI'><![CDATA[ <example caption='Roster Action With Name: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?roster;name=Romeo%20Montague xmpp:romeo@montague.net?roster;name=Romeo%20Montague
]]></example> ]]></example>
<example caption='Roster Action With Name: Resulting Stanza'><![CDATA[ <example caption='Roster Action With Name: Resulting Stanza'><![CDATA[
<iq type='set'> <iq type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net' name='Romeo Montague'/> <item jid='romeo@montague.net' name='Romeo Montague'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Roster Action With Name and Group: IRI/URI'><![CDATA[ <example caption='Roster Action With Name and Group: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?roster;name=Romeo%20Montague;group=Friends xmpp:romeo@montague.net?roster;name=Romeo%20Montague;group=Friends
]]></example> ]]></example>
<example caption='Roster Action With Name and Group: Resulting Stanza'><![CDATA[ <example caption='Roster Action With Name and Group: Resulting Stanza'><![CDATA[
<iq type='set'> <iq type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
@ -179,21 +179,21 @@ xmpp:romeo@montague.net?roster;name=Romeo%20Montague;group=Friends
</item> </item>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Note: Methods (if any) for including more than one group are yet to be determined.</p> <p>Note: Methods (if any) for including more than one group are yet to be determined.</p>
</section3> </section3>
<section3 topic='Remove Roster Item' anchor='actions-roster-remove'> <section3 topic='Remove Roster Item' anchor='actions-roster-remove'>
<p>The 'jabber:iq:roster' namespace includes a mechanism for removing an XMPP roster item. The registered querytype for removing an item from the roster is "remove".</p> <p>The 'jabber:iq:roster' namespace includes a mechanism for removing an XMPP roster item. The registered querytype for removing an item from the roster is "remove".</p>
<example caption='Roster Removal Action: IRI/URI'><![CDATA[ <example caption='Roster Removal Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?remove xmpp:romeo@montague.net?remove
]]></example> ]]></example>
<example caption='Roster Removal Action: Resulting Stanza'><![CDATA[ <example caption='Roster Removal Action: Resulting Stanza'><![CDATA[
<iq type='set'> <iq type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net' subscription='remove'/> <item jid='romeo@montague.net' subscription='remove'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Subscription Management Actions' anchor='actions-sub'> <section2 topic='Subscription Management Actions' anchor='actions-sub'>
@ -202,7 +202,7 @@ xmpp:romeo@montague.net?remove
<p>When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in <cite>RFC 3921</cite>).</p> <p>When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in <cite>RFC 3921</cite>).</p>
<example caption='Subscribe Action: IRI/URI'><![CDATA[ <example caption='Subscribe Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?subscribe xmpp:romeo@montague.net?subscribe
]]></example> ]]></example>
<example caption='Subscribe Action: Resulting Stanzas'><![CDATA[ <example caption='Subscribe Action: Resulting Stanzas'><![CDATA[
<iq type='set'> <iq type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
@ -211,16 +211,16 @@ xmpp:romeo@montague.net?subscribe
</iq> </iq>
<presence to='romeo@montague.net' type='subscribe'/> <presence to='romeo@montague.net' type='subscribe'/>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Unsubscribe' anchor='actions-sub-unsubscribe'> <section3 topic='Unsubscribe' anchor='actions-sub-unsubscribe'>
<p>XMPP includes a mechanism for unsubscribing from an entity. The registered querytype for doing so is "unsubscribe".</p> <p>XMPP includes a mechanism for unsubscribing from an entity. The registered querytype for doing so is "unsubscribe".</p>
<example caption='Unsubscribe Action: IRI/URI'><![CDATA[ <example caption='Unsubscribe Action: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?unsubscribe xmpp:romeo@montague.net?unsubscribe
]]></example> ]]></example>
<example caption='Unsubscribe Action: Resulting Stanza'><![CDATA[ <example caption='Unsubscribe Action: Resulting Stanza'><![CDATA[
<presence to='romeo@montague.net' type='unsubscribe'/> <presence to='romeo@montague.net' type='unsubscribe'/>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -262,7 +262,7 @@ xmpp:romeo@montague.net?unsubscribe
</key> </key>
</keys> </keys>
</querytype> </querytype>
]]></code> ]]></code>
<p>Note: Within the &lt;querytype/&gt; element, the &lt;keys/&gt; child element is OPTIONAL; within any given &lt;key/&gt; element, the &lt;values/&gt; child element is also OPTIONAL.</p> <p>Note: Within the &lt;querytype/&gt; element, the &lt;keys/&gt; child element is OPTIONAL; within any given &lt;key/&gt; element, the &lt;values/&gt; child element is also OPTIONAL.</p>
<p>The registrant may register more than one querytype at a time, each contained in a separate &lt;querytype/&gt; element.</p> <p>The registrant may register more than one querytype at a time, each contained in a separate &lt;querytype/&gt; element.</p>
</section3> </section3>
@ -359,7 +359,7 @@ xmpp:romeo@montague.net?unsubscribe
<doc>XEP-0147</doc> <doc>XEP-0147</doc>
</querytype> </querytype>
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
</section1> </section1>

18
xep-0148.xml
View File

@ -46,7 +46,7 @@
id='imiq1'> id='imiq1'>
<query xmlns='jabber:iq:iq'/> <query xmlns='jabber:iq:iq'/>
</iq> </iq>
]]></example> ]]></example>
<p>The server then returns the person's IM IQ, expressed as a REQUIRED &lt;num/&gt; integer between zero and 256, and an OPTIONAL &lt;desc/&gt; containing a natural-language descriptive phrase associated with that range of integer values.</p> <p>The server then returns the person's IM IQ, expressed as a REQUIRED &lt;num/&gt; integer between zero and 256, and an OPTIONAL &lt;desc/&gt; containing a natural-language descriptive phrase associated with that range of integer values.</p>
<example caption='Receiving Someone&apos;s IM IQ'><![CDATA[ <example caption='Receiving Someone&apos;s IM IQ'><![CDATA[
<iq type='result' <iq type='result'
@ -58,7 +58,7 @@
<desc>moron</desc> <desc>moron</desc>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Discovering One&apos;s Own IM IQ' anchor='disco-own'> <section2 topic='Discovering One&apos;s Own IM IQ' anchor='disco-own'>
<p>In order for a user to discover his or her own IM IQ, the user sends an IQ get without any 'to' address.</p> <p>In order for a user to discover his or her own IM IQ, the user sends an IQ get without any 'to' address.</p>
@ -66,7 +66,7 @@
<iq type='get' id='myiq'> <iq type='get' id='myiq'>
<query xmlns='jabber:iq:iq'/> <query xmlns='jabber:iq:iq'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Receiving One&apos;s Own IM IQ'><![CDATA[ <example caption='Receiving One&apos;s Own IM IQ'><![CDATA[
<iq type='result' id='myiq'> <iq type='result' id='myiq'>
<query xmlns='jabber:iq:iq'> <query xmlns='jabber:iq:iq'>
@ -74,7 +74,7 @@
<desc>dull</desc> <desc>dull</desc>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>A user may not agree with his or her IM IQ as computed by the server (after all, everyone thinks they are above average). Therefore it is possible that a user may attempt to change his or her IM IQ by sending an IQ set to the server:</p> <p>A user may not agree with his or her IM IQ as computed by the server (after all, everyone thinks they are above average). Therefore it is possible that a user may attempt to change his or her IM IQ by sending an IQ set to the server:</p>
<example caption='Attempting to Set One&apos;s Own IM IQ'><![CDATA[ <example caption='Attempting to Set One&apos;s Own IM IQ'><![CDATA[
<iq type='set' id='myiq'> <iq type='set' id='myiq'>
@ -83,7 +83,7 @@
<desc>genius</desc> <desc>genius</desc>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>However, allowing users to change their own IM IQs is unacceptable, since it would make such information unreliable. Therefore, if a server receives such an IQ set, it MUST return a &notallowed; error to the user, and MAY further decrement the user's IM IQ as a result.</p> <p>However, allowing users to change their own IM IQs is unacceptable, since it would make such information unreliable. Therefore, if a server receives such an IQ set, it MUST return a &notallowed; error to the user, and MAY further decrement the user's IM IQ as a result.</p>
<example caption='Server Returns Error to User on Attempted Set'><![CDATA[ <example caption='Server Returns Error to User on Attempted Set'><![CDATA[
<iq type='error' id='myiq'> <iq type='error' id='myiq'>
@ -95,7 +95,7 @@
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Messaging Hints' anchor='hints'> <section2 topic='Messaging Hints' anchor='hints'>
<p>Even smart people say stupid things, and we are all familiar with the experience of having said something stupid (or just average) and realizing later that one could have said something exceedingly clever. To prevent people from saying stupid things and to help users appear as smart as possible, the mod_iq jabberd module provides hints to users regarding what to say at a given point in a conversation, based on the advanced linguistic analysis technologies described under <link url='#impl'>Implementation Notes</link> below. A user can ask for a hint by sending the complete message to the server itself, wrapped in a &QUERY; element qualified by the 'jabber:iq:iq' namespace. (While it may be argued that this functionality could be provided client-side, thus saving a roundtrip, it is consistent with the Jabber philosophy of "smart servers, dumb clients" as explained in &xep0134;.)</p> <p>Even smart people say stupid things, and we are all familiar with the experience of having said something stupid (or just average) and realizing later that one could have said something exceedingly clever. To prevent people from saying stupid things and to help users appear as smart as possible, the mod_iq jabberd module provides hints to users regarding what to say at a given point in a conversation, based on the advanced linguistic analysis technologies described under <link url='#impl'>Implementation Notes</link> below. A user can ask for a hint by sending the complete message to the server itself, wrapped in a &QUERY; element qualified by the 'jabber:iq:iq' namespace. (While it may be argued that this functionality could be provided client-side, thus saving a roundtrip, it is consistent with the Jabber philosophy of "smart servers, dumb clients" as explained in &xep0134;.)</p>
@ -111,7 +111,7 @@
</message> </message>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The server then determines a more intelligent message to send and returns the XML character data of the &BODY; element to the user in a &lt;hint/&gt; element.</p> <p>The server then determines a more intelligent message to send and returns the XML character data of the &BODY; element to the user in a &lt;hint/&gt; element.</p>
<example caption='Server Hints at a More Intelligent Message'><![CDATA[ <example caption='Server Hints at a More Intelligent Message'><![CDATA[
<iq type='result' <iq type='result'
@ -126,7 +126,7 @@
</hint> </hint>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Messages checked with the server before sending SHOULD NOT affect the user's IM IQ computation; however, the server MAY decrement the user's IM IQ more significantly if the user ends up sending the original message rather than the smarter one provided by the server.</p> <p>Messages checked with the server before sending SHOULD NOT affect the user's IM IQ computation; however, the server MAY decrement the user's IM IQ more significantly if the user ends up sending the original message rather than the smarter one provided by the server.</p>
</section2> </section2>
</section1> </section1>
@ -239,6 +239,6 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

8
xep-0149.xml
View File

@ -86,7 +86,7 @@
<header name='Stop'>2005-03-17T11:30:00Z</header> <header name='Stop'>2005-03-17T11:30:00Z</header>
</headers> </headers>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='User Activity' anchor='activity'> <section2 topic='User Activity' anchor='activity'>
<p>An XMPP extension for user activity is specified in <cite>XEP-0108</cite>. It may be desirable to include time period information when publishing one's activity.</p> <p>An XMPP extension for user activity is specified in <cite>XEP-0108</cite>. It may be desirable to include time period information when publishing one's activity.</p>
@ -112,7 +112,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='User Mood' anchor='mood'> <section2 topic='User Mood' anchor='mood'>
<p>An XMPP extension for user mood is specified in <cite>XEP-0107</cite>. It may be desirable to include time period information when publishing one's mood.</p> <p>An XMPP extension for user mood is specified in <cite>XEP-0107</cite>. It may be desirable to include time period information when publishing one's mood.</p>
@ -135,7 +135,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>Note that the start time is (intended to be) retroactive.</p> <p>Note that the start time is (intended to be) retroactive.</p>
</section2> </section2>
</section1> </section1>
@ -163,7 +163,7 @@
<desc>The dateTime at which a state, event, or activity stops</desc> <desc>The dateTime at which a state, event, or activity stops</desc>
<doc>XEP-0149</doc> <doc>XEP-0149</doc>
</header> </header>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

36
xep-0150.xml
View File

@ -64,7 +64,7 @@
id='roster1'> id='roster1'>
<query xmlns='jabber:iq:roster'/> <query xmlns='jabber:iq:roster'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Returns Roster Including ETag Header'><![CDATA[ <example caption='Server Returns Roster Including ETag Header'><![CDATA[
<iq type='result' <iq type='result'
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
@ -81,7 +81,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<example caption='Client Requests Roster Including If-None-Match Header'><![CDATA[ <example caption='Client Requests Roster Including If-None-Match Header'><![CDATA[
<iq type='get' <iq type='get'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
@ -92,7 +92,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the responding entity does not understand the If-None-Match header or does not handle Entity Tags for the namespace in the request, it MUST ignore the header and return whatever information it would have returned if the header had not been present.</p> <p>If the responding entity does not understand the If-None-Match header or does not handle Entity Tags for the namespace in the request, it MUST ignore the header and return whatever information it would have returned if the header had not been present.</p>
<p>If the responding entity determines that the requested information has not changed since it was last retrieved by the requesting entity, then it MUST return a &lt;not-modified/&gt; error corresponding to the HTTP 304 error returned by HTTP entities that support the ETag header:</p> <p>If the responding entity determines that the requested information has not changed since it was last retrieved by the requesting entity, then it MUST return a &lt;not-modified/&gt; error corresponding to the HTTP 304 error returned by HTTP entities that support the ETag header:</p>
<example caption='Responding Entity Returns Not Modified Error'><![CDATA[ <example caption='Responding Entity Returns Not Modified Error'><![CDATA[
@ -108,7 +108,7 @@
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Note: The &lt;not-modified/&gt; error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the &lt;not-modified/&gt; error condition is included in &xmppcore;.</p> <p>Note: The &lt;not-modified/&gt; error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the &lt;not-modified/&gt; error condition is included in &xmppcore;.</p>
<p>Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of <cite>RFC 2616</cite>); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.</p> <p>Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of <cite>RFC 2616</cite>); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.</p>
<p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.</p> <p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.</p>
@ -123,7 +123,7 @@
id='roster1'> id='roster1'>
<query xmlns='jabber:iq:roster'/> <query xmlns='jabber:iq:roster'/>
</iq> </iq>
]]></example> ]]></example>
<p>If the server supports Entity Tag functionality for rosters, it SHOULD include an ETag SHIM header in its response (although it MAY decide not to include the header if the roster is deemed to be not worth caching because it is so small):</p> <p>If the server supports Entity Tag functionality for rosters, it SHOULD include an ETag SHIM header in its response (although it MAY decide not to include the header if the roster is deemed to be not worth caching because it is so small):</p>
<example caption='Server Returns Roster Including ETag Header'><![CDATA[ <example caption='Server Returns Roster Including ETag Header'><![CDATA[
<iq type='result' <iq type='result'
@ -141,7 +141,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The client would then cache that roster and associate the included Entity Tag with that cached copy. In order to subsequently retrieve the roster, the client would include the last known Entity Tag value with the request in an If-None-Match SHIM header:</p> <p>The client would then cache that roster and associate the included Entity Tag with that cached copy. In order to subsequently retrieve the roster, the client would include the last known Entity Tag value with the request in an If-None-Match SHIM header:</p>
<example caption='Client Requests Roster, Including If-None-Match Header'><![CDATA[ <example caption='Client Requests Roster, Including If-None-Match Header'><![CDATA[
<iq type='get' <iq type='get'
@ -153,7 +153,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the roster did not change since the client last retrieved the roster and the server supports Entity Tags for the 'jabber:iq:roster' namespace, the server MUST return a &lt;not-modified/&gt; error:</p> <p>If the roster did not change since the client last retrieved the roster and the server supports Entity Tags for the 'jabber:iq:roster' namespace, the server MUST return a &lt;not-modified/&gt; error:</p>
<example caption='Server Returns Not Modified Error'><![CDATA[ <example caption='Server Returns Not Modified Error'><![CDATA[
<iq type='error' <iq type='error'
@ -168,7 +168,7 @@
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the roster has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the roster as if the If-None-Match header was not included:</p> <p>If the roster has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the roster as if the If-None-Match header was not included:</p>
<example caption='Server Returns Roster'><![CDATA[ <example caption='Server Returns Roster'><![CDATA[
<iq type='result' <iq type='result'
@ -186,7 +186,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Caching and Retrieving Privacy Lists' anchor='privacy'> <section2 topic='Caching and Retrieving Privacy Lists' anchor='privacy'>
<p>The payloads exchanged in the &xep0016; protocol can also be quite large. Therefore a server might want to support Entity Tags in the context of privacy list management. The process is as follows.</p> <p>The payloads exchanged in the &xep0016; protocol can also be quite large. Therefore a server might want to support Entity Tags in the context of privacy list management. The process is as follows.</p>
@ -199,7 +199,7 @@
<list name='special'/> <list name='special'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The server returns the list and includes an Entity Tag in an ETag SHIM header.</p> <p>The server returns the list and includes an Entity Tag in an ETag SHIM header.</p>
<example caption='Server Returns Privacy List Including ETag Header'><![CDATA[ <example caption='Server Returns Privacy List Including ETag Header'><![CDATA[
<iq type='result' <iq type='result'
@ -226,7 +226,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:</p> <p>Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:</p>
<example caption='Client Requests Privacy List Including If-None-Match Header'><![CDATA[ <example caption='Client Requests Privacy List Including If-None-Match Header'><![CDATA[
<iq type='get' <iq type='get'
@ -239,7 +239,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the privacy list did not change since the client last retrieved it and the server supports Entity Tags for the 'jabber:iq:privacy' namespace, the server MUST return a &lt;not-modified/&gt; error:</p> <p>If the privacy list did not change since the client last retrieved it and the server supports Entity Tags for the 'jabber:iq:privacy' namespace, the server MUST return a &lt;not-modified/&gt; error:</p>
<example caption='Server Returns Not Modified Error'><![CDATA[ <example caption='Server Returns Not Modified Error'><![CDATA[
<iq type='error' <iq type='error'
@ -255,7 +255,7 @@
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If the privacy list has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the privacy list as if the If-None-Match header was not included:</p> <p>If the privacy list has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the privacy list as if the If-None-Match header was not included:</p>
<example caption='Server Returns Privacy List'><![CDATA[ <example caption='Server Returns Privacy List'><![CDATA[
<iq type='result' <iq type='result'
@ -282,7 +282,7 @@
</headers> </headers>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Discovering Support' anchor='disco'> <section2 topic='Discovering Support' anchor='disco'>
<p><cite>XEP-0131</cite> specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:</p> <p><cite>XEP-0131</cite> specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:</p>
@ -293,7 +293,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim'/> node='http://jabber.org/protocol/shim'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Communicates Supported SHIM Headers'><![CDATA[ <example caption='Server Communicates Supported SHIM Headers'><![CDATA[
<iq from='capulet.com' <iq from='capulet.com'
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
@ -306,7 +306,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.</p> <p>The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.</p>
<p>Note: If an XMPP entity supports Entity Tags as specified herein, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.</p> <p>Note: If an XMPP entity supports Entity Tags as specified herein, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.</p>
<p>Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.</p> <p>Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.</p>
@ -318,7 +318,7 @@
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim#ETag'/> node='http://jabber.org/protocol/shim#ETag'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server Communicates Supported Entity Tag Namespaces'><![CDATA[ <example caption='Server Communicates Supported Entity Tag Namespaces'><![CDATA[
<iq from='capulet.com' <iq from='capulet.com'
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
@ -331,7 +331,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>Alternatively, as shown above and as used in HTTP, the requesting entity MAY implicitly discover that Entity Tag functionality is supported with regard to a given response entity type if the responding entity includes an ETag SHIM header in its response.</p> <p>Alternatively, as shown above and as used in HTTP, the requesting entity MAY implicitly discover that Entity Tag functionality is supported with regard to a given response entity type if the responding entity includes an ETag SHIM header in its response.</p>
</section2> </section2>
</section1> </section1>

22
xep-0152.xml
View File

@ -109,7 +109,7 @@
<addr uri='tel:+1-303-555-1212'/> <addr uri='tel:+1-303-555-1212'/>
<addr uri='sip:room123@example.com'/> <addr uri='sip:room123@example.com'/>
</reach> </reach>
]]></example> ]]></example>
<p>When publishing reachability addresses, the &lt;reach/&gt; element MUST contain at least one &lt;addr/&gt; element. Each &lt;addr/&gt; element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.</p> <p>When publishing reachability addresses, the &lt;reach/&gt; element MUST contain at least one &lt;addr/&gt; element. Each &lt;addr/&gt; element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.</p>
<p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see &rfc6120;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachability data via presence broadcast, but MAY be included when using directed presence or the personal eventing protocol.</p> <p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see &rfc6120;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachability data via presence broadcast, but MAY be included when using directed presence or the personal eventing protocol.</p>
<example caption="Reachability Addresses With Descriptions"><![CDATA[ <example caption="Reachability Addresses With Descriptions"><![CDATA[
@ -121,7 +121,7 @@
<desc xml:lang='en'>In-room video system</desc> <desc xml:lang='en'>In-room video system</desc>
</addr> </addr>
</reach> </reach>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Data Transport' anchor='transport'> <section1 topic='Data Transport' anchor='transport'>
@ -143,7 +143,7 @@
<addr uri='sip:room123@example.com'/> <addr uri='sip:room123@example.com'/>
</reach> </reach>
</presence> </presence>
]]></example> ]]></example>
<p>The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:</p> <p>The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:</p>
<example caption="User&apos;s Server Broadcasts Presence Information"><![CDATA[ <example caption="User&apos;s Server Broadcasts Presence Information"><![CDATA[
<presence from='romeo@montague.net/mobile' to='juliet@capulet.com'> <presence from='romeo@montague.net/mobile' to='juliet@capulet.com'>
@ -152,12 +152,12 @@
<addr uri='sip:room123@example.com'/> <addr uri='sip:room123@example.com'/>
</reach> </reach>
</presence> </presence>
]]></example> ]]></example>
<p>(Naturally, a reachability address MAY alternatively be included in directed presence.)</p> <p>(Naturally, a reachability address MAY alternatively be included in directed presence.)</p>
<p>Upon leaving the conference room, the user's client would send updated presence without the reachability extension.</p> <p>Upon leaving the conference room, the user's client would send updated presence without the reachability extension.</p>
<example caption="User&apos;s Client Sends Updated Presence Without Reachability Addresses"><![CDATA[ <example caption="User&apos;s Client Sends Updated Presence Without Reachability Addresses"><![CDATA[
<presence from='romeo@example.com/mobile'/> <presence from='romeo@example.com/mobile'/>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Personal Eventing Protocol' anchor='transport-pep'> <section2 topic='Personal Eventing Protocol' anchor='transport-pep'>
@ -182,7 +182,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<example caption='Subscriber Receives PEP Event with Payload'><![CDATA[ <example caption='Subscriber Receives PEP Event with Payload'><![CDATA[
<message from='pubsub.shakespeare.lit' <message from='pubsub.shakespeare.lit'
to='juliet@capulet.com'> to='juliet@capulet.com'>
@ -201,7 +201,7 @@
</items> </items>
</event> </event>
</message> </message>
]]></example> ]]></example>
<p>As above, when leaving the conference room the user's client would publish an updated payload indicating that it no longer has any temporary reachability addresses.</p> <p>As above, when leaving the conference room the user's client would publish an updated payload indicating that it no longer has any temporary reachability addresses.</p>
<example caption='Entity Publishes Payload with Empty Reachability Addresses'><![CDATA[ <example caption='Entity Publishes Payload with Empty Reachability Addresses'><![CDATA[
<iq type='set' <iq type='set'
@ -216,7 +216,7 @@
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -229,7 +229,7 @@
type='get'> type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery Information Response"><![CDATA[ <example caption="Service Discovery Information Response"><![CDATA[
<iq from='romeo@montague.net/orchard' <iq from='romeo@montague.net/orchard'
id='disco1' id='disco1'
@ -239,7 +239,7 @@
<feature var='urn:xmpp:reach:0'/> <feature var='urn:xmpp:reach:0'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<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>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>
</section1> </section1>
@ -313,6 +313,6 @@
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
</xep> </xep>

16
xep-0153.xml
View File

@ -106,10 +106,10 @@
</PHOTO> </PHOTO>
</vCard> </vCard>
</iq> </iq>
]]></example> ]]></example>
<example caption="User&apos;s Server Acknowledges Publish"><![CDATA[ <example caption="User&apos;s Server Acknowledges Publish"><![CDATA[
<iq to='juliet@capulet.com' type='result' id='vc1'/> <iq to='juliet@capulet.com' type='result' id='vc1'/>
]]></example> ]]></example>
<p>Next, the user's client computes the SHA1 hash of the avatar image data itself (not the base64-encoded version) in accordance with &rfc3174;. This hash is then included in the user's presence information as the XML character data of the &lt;photo/&gt; child of an &X; element qualified by the 'vcard-temp:x:update' namespace, as shown in the following example:</p> <p>Next, the user's client computes the SHA1 hash of the avatar image data itself (not the base64-encoded version) in accordance with &rfc3174;. This hash is then included in the user's presence information as the XML character data of the &lt;photo/&gt; child of an &X; element qualified by the 'vcard-temp:x:update' namespace, as shown in the following example:</p>
<example caption="User&apos;s Client Includes Avatar Hash in Presence Broadcast"><![CDATA[ <example caption="User&apos;s Client Includes Avatar Hash in Presence Broadcast"><![CDATA[
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@capulet.com/balcony'>
@ -117,7 +117,7 @@
<photo>sha1-hash-of-image</photo> <photo>sha1-hash-of-image</photo>
</x> </x>
</presence> </presence>
]]></example> ]]></example>
<p>The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.</p> <p>The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.</p>
</section2> </section2>
<section2 topic='Contact Retrieves Avatar' anchor='retrieve'> <section2 topic='Contact Retrieves Avatar' anchor='retrieve'>
@ -129,7 +129,7 @@
id='vc2'> id='vc2'>
<vCard xmlns='vcard-temp'/> <vCard xmlns='vcard-temp'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Server Returns vCard on Behalf of User"><![CDATA[ <example caption="Server Returns vCard on Behalf of User"><![CDATA[
<iq from='juliet@capulet.com' <iq from='juliet@capulet.com'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
@ -153,7 +153,7 @@
</PHOTO> </PHOTO>
</vCard> </vCard>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
@ -167,7 +167,7 @@
<presence> <presence>
<x xmlns='vcard-temp:x:update'/> <x xmlns='vcard-temp:x:update'/>
</presence> </presence>
]]></example> ]]></example>
</li> </li>
<li> <li>
<p>If there is no avatar image to be advertised, the photo element MUST be empty, i.e.:</p> <p>If there is no avatar image to be advertised, the photo element MUST be empty, i.e.:</p>
@ -177,7 +177,7 @@
<photo/> <photo/>
</x> </x>
</presence> </presence>
]]></example> ]]></example>
<p>If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the &lt;photo/&gt; element.</p> <p>If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the &lt;photo/&gt; element.</p>
<p>Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).</p> <p>Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).</p>
</li> </li>
@ -276,7 +276,7 @@
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.</p> <p>The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.</p>

Some files were not shown because too many files have changed in this diff Show More