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

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

sed -i 's/^\s\+]]>/]]>/g' xep-*.xml
hacx
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:schema>
]]></code>
]]></code>
</section1>
</xep>

30
xep-0003.xml
View File

@ -90,14 +90,14 @@
<expire>600</expire>
</query>
</iq>
]]></example>
]]></example>
<example caption='Result from PASS Service'><![CDATA[
<iq id='pass1' type='result' from='pass.jabber.org'>
<query xmlns='jabber:iq:pass'>
<server port='43253'>1.2.3.4</server>
</query>
</iq>
]]></example>
]]></example>
<p>At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.</p>
<p>The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an &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'>
@ -125,7 +125,7 @@
<proxy port='43523'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<example caption='IQ result to accept connection'><![CDATA[
<iq type='result'
id='pass2'
@ -133,7 +133,7 @@
to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<p>The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.</p>
<p>Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.</p>
</section1>
@ -152,7 +152,7 @@
<proxy port='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<example caption='Acknowledgement of expiration'><![CDATA[
<iq type='result'
id='pass3'
@ -160,7 +160,7 @@
to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -175,7 +175,7 @@
<proxy port='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<example caption='Client acknowledges closing of oneshot port'><![CDATA[
<iq type='result'
id='pass4'
@ -183,7 +183,7 @@
to='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -197,7 +197,7 @@
<proxy port='43253'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges port closing request'><![CDATA[
<iq type='result'
id='pass5'
@ -205,7 +205,7 @@
from='pass.jabber.org'>
<query xmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<table caption='Error Codes'>
<tr>
<th>Code</th>
@ -246,7 +246,7 @@
from='you@jabber.org/resource'>
<query xmlns='jabber:iq:pass'/>
</iq>
]]></example>
]]></example>
<p>The other client SHOULD send back:</p>
<example><![CDATA[
<iq type='result'
@ -257,7 +257,7 @@
<client>4.3.2.1</client>
</query>
</iq>
]]></example>
]]></example>
<p>Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the &lt;client/&gt; information upon a connection.</p>
</section2>
<section2 topic='Denying a Connection'>
@ -273,7 +273,7 @@
<proxy port='43523'>1.2.3.4</proxy>
</query>
</iq>
]]></example>
]]></example>
<p>Your client would send back:</p>
<example><![CDATA[
<iq type='error'
@ -288,7 +288,7 @@
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
<table caption='Error Codes'>
<tr>
<th>Code</th>
@ -354,6 +354,6 @@
</xs:simpleType>
</xs:schema>
]]></code>
]]></code>
</section1>
</xep>

26
xep-0004.xml
View File

@ -169,7 +169,7 @@
<option label='option-label'><value>option-value</value></option>
</field>
</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 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'>
@ -299,7 +299,7 @@
.
.
</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>
</section2>
</section1>
@ -321,7 +321,7 @@
node='create'
action='execute'/>
</iq>
]]></example>
]]></example>
<p>The hosting service then returns a data form to the user:</p>
<example caption="Service Returns Bot Creation Form"><![CDATA[
<iq from='joogle@botster.shakespeare.lit'
@ -388,7 +388,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
<p>The user then submits the configuration form:</p>
<example caption="User Submits Bot Creation Form"><![CDATA[
<iq from='romeo@montague.net/home'
@ -432,7 +432,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
<p>The service then returns the results to the user:</p>
<example caption="Service Returns Bot Creation Result"><![CDATA[
<iq from='joogle@botster.shakespeare.lit'
@ -471,7 +471,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -485,7 +485,7 @@
node='search'
action='execute'/>
</iq>
]]></example>
]]></example>
<example caption="Service Returns Search Form"><![CDATA[
<iq from='joogle@botster.shakespeare.lit'
to='juliet@capulet.com/chamber'
@ -505,7 +505,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
<example caption="User Submits Search Form"><![CDATA[
<iq from='juliet@capulet.com/chamber'
to='joogle@botster.shakespeare.lit'
@ -521,7 +521,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
<example caption="Service Returns Search Results"><![CDATA[
<iq from='joogle@botster.shakespeare.lit'
to='juliet@capulet.com/chamber'
@ -580,7 +580,7 @@
</x>
</command>
</iq>
]]></example>
]]></example>
</section2>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
@ -592,7 +592,7 @@
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
]]></example>
<example caption="Service Discovery information response"><![CDATA[
<iq type='result'
from='juliet@capulet.com/balcony'
@ -604,7 +604,7 @@
...
</query>
</iq>
]]></example>
]]></example>
<p>If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -733,7 +733,7 @@
</xs:simpleType>
</xs:schema>
]]></code>
]]></code>
</section1>
<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>

12
xep-0009.xml
View File

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

2
xep-0011.xml
View File

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

28
xep-0012.xml
View File

@ -87,7 +87,7 @@
type='get'>
<query xmlns='jabber:iq:last'/>
</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>
<example caption='Last Activity Response'><![CDATA[
<iq from='juliet@capulet.com'
@ -96,7 +96,7 @@
type='result'>
<query xmlns='jabber:iq:last' seconds='903'/>
</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>
<ol>
<li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li>
@ -114,7 +114,7 @@
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<p>As specified in &xmppcore; and &xmppim;, an IQ stanza of type "get" sent to a bare JID &LOCALBARE; is handled by the user's server on the user's behalf, not delivered to one or more connected or available resources.</p>
<p>If the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP-IM</cite>), the user's server MUST NOT return last activity information but instead MUST return a &forbidden; error in response to the last activity request.</p>
<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'/>
</error>
</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>
<example caption='Last Activity Response by Server'><![CDATA[
<iq from='juliet@capulet.com'
@ -135,7 +135,7 @@
type='result'>
<query xmlns='jabber:iq:last' seconds='903'>Heading Home</query>
</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>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>
@ -148,7 +148,7 @@
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<p>In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user.</p>
<p>In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP IM</cite>), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a &forbidden; error in response to the last activity request.</p>
<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'/>
</error>
</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>
<example caption='Last Activity Response by Client'><![CDATA[
<iq from='juliet@capulet.com/balcony'
@ -169,7 +169,7 @@
type='result'>
<query xmlns='jabber:iq:last' seconds='123'/>
</iq>
]]></example>
]]></example>
<p>In the foregoing example, the user has been idle for about two minutes.</p>
<p>Support for this functionality is OPTIONAL. A client that does not support the protocol, or that does not wish to divulge this information, MUST return a &unavailable; error.</p>
<example caption='Service Unavailable Error'><![CDATA[
@ -181,7 +181,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
</section1>
<section1 topic='Server and Component Query' anchor='server'>
@ -193,7 +193,7 @@
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
]]></example>
]]></example>
<example caption='Last Activity Response from Server or Service'><![CDATA[
<iq from='capulet.com'
id='last3'
@ -201,7 +201,7 @@
type='result'>
<query xmlns='jabber:iq:last' seconds='123456'/>
</iq>
]]></example>
]]></example>
<p>In this example, the server has been running for a little more than 34 hours.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
@ -213,7 +213,7 @@
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
]]></example>
<example caption='Responding entity communicates protocol support'><![CDATA[
<iq from='jabber.org'
id='disco1'
@ -223,7 +223,7 @@
<feature var='jabber:iq:last'/>
</query>
</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>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
@ -270,6 +270,6 @@
</xs:element>
</xs:schema>
]]></code>
]]></code>
</section1>
</xep>

34
xep-0013.xml
View File

@ -124,7 +124,7 @@
<iq type='get' to='montague.net'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
]]></example>
<example caption='Server Reply to Discovery Request'><![CDATA[
<iq type='result'
from='montague.net'
@ -133,7 +133,7 @@
<feature var='http://jabber.org/protocol/offline'/>
</query>
</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>
</section2>
<section2 topic='Requesting Number of Messages' anchor='request-number'>
@ -144,7 +144,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/offline'/>
</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>
<example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'>
@ -164,7 +164,7 @@
</x>
</query>
</iq>
]]></example>
]]></example>
<p>Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.</p>
</section2>
<section2 topic='Requesting Message Headers' anchor='request-headers'>
@ -174,7 +174,7 @@
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'/>
</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>
<example caption='Server Provides Offline Message Headers'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'>
@ -202,7 +202,7 @@
name='juliet@capulet.com/balcony'/>
</query>
</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>The syntax and semantics of the attributes are as follows:</p>
<ul>
@ -220,7 +220,7 @@
node='2003-02-27T22:52:37.225Z'/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an &notfound; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p>
<example caption='Server Provides Offline Messages'><![CDATA[
<message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@ -231,7 +231,7 @@
</message>
<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>
</section2>
<section2 topic='Removing Specific Messages' anchor='remove-specific'>
@ -246,11 +246,11 @@
node='2003-02-27T22:52:37.225Z'/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove the messages and inform the user:</p>
<example caption='Server Informs User of Removal'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='remove1'/>
]]></example>
]]></example>
</section2>
<section2 topic='Retrieving All Messages' anchor='retrieve-all'>
<p>The user retrieves all message by sending the "fetch" command:</p>
@ -260,7 +260,7 @@
<fetch/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &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[
<message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@ -271,7 +271,7 @@
</message>
<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>
</section2>
<section2 topic='Removing All Messages' anchor='remove-all'>
@ -282,11 +282,11 @@
<purge/>
</offline>
</iq>
]]></example>
]]></example>
<p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove all messages and inform the user:</p>
<example caption='Server Informs User of Successful Purge'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard' id='purge1'/>
]]></example>
]]></example>
</section2>
</section1>
<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>
</type>
</category>
]]></code>
]]></code>
</section2>
<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>
@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc.
type='text-single'
label='N/A'/>
</form_type>
]]></code>
]]></code>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
</xs:element>
</xs:schema>
]]></code>
]]></code>
</section1>
</xep>

112
xep-0016.xml
View File

@ -132,7 +132,7 @@
</list>
</query>
</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>
<ol>
<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'>
<query xmlns='jabber:iq:privacy'/>
</iq>
]]></example>
]]></example>
<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'>
<query xmlns='jabber:iq:privacy'>
@ -187,14 +187,14 @@
<list name='special'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Client requests a privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server sends a privacy list to client'><![CDATA[
<iq type='result' id='getlist2' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
@ -207,14 +207,14 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<example caption='Client requests another privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist3'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server sends another privacy list to client'><![CDATA[
<iq type='result' id='getlist3' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
@ -227,14 +227,14 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<example caption='Client requests yet another privacy list from server'><![CDATA[
<iq from='romeo@example.net/orchard' type='get' id='getlist4'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server sends yet another privacy list to client'><![CDATA[
<iq type='result' id='getlist4' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
@ -255,7 +255,7 @@
</list>
</query>
</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>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[
@ -268,7 +268,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
<p>The user is allowed to retrieve only one list at a time. If the user attempts to retrieve more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user:</p>
<example caption='Client attempts to retrieve more than one list'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='getlist6'>
@ -282,7 +282,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -292,11 +292,11 @@
<active name='special'/>
</query>
</iq>
]]></example>
]]></example>
<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[
<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>
<example caption='Client attempts to set a non-existent list as active'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='active2'>
@ -308,7 +308,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
<example caption='Client declines the use of active lists'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='active3'>
@ -316,10 +316,10 @@
<active/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges success of declining any active list'><![CDATA[
<iq type='result' id='active3' to='romeo@example.net/orchard'/>
]]></example>
]]></example>
</section2>
<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>
@ -329,10 +329,10 @@
<default name='special'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges success of default list change'><![CDATA[
<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>
<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'>
@ -344,7 +344,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
<example caption='Client attempts to set a non-existent list as default'><![CDATA[
<iq to='romeo@example.net/orchard' type='error' id='default1'>
@ -356,7 +356,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
<example caption='Client declines the use of the default list'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='default2'>
@ -364,10 +364,10 @@
<default/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges success of declining any default list'><![CDATA[
<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>
<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'>
@ -379,7 +379,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -399,10 +399,10 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges success of list edit'><![CDATA[
<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>The server MUST now send a "privacy list push" to all connected resources:</p>
<example caption='Privacy list push on list edit'><![CDATA[
@ -417,7 +417,7 @@
<list name='public'/>
</query>
</iq>
]]></example>
]]></example>
<p>In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:</p>
<example caption='Acknowledging receipt of privacy list pushes'><![CDATA[
<iq from='romeo@example.net/orchard'
@ -427,7 +427,7 @@
<iq from='romeo@example.net/home'
type='result'
id='push2'/>
]]></example>
]]></example>
</section2>
<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>
@ -440,10 +440,10 @@
<list name='private'/>
</query>
</iq>
]]></example>
]]></example>
<example caption='Server acknowledges success of list removal'><![CDATA[
<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>
</section2>
<section2 topic="Blocking Messages" anchor="protocol-message">
@ -461,7 +461,7 @@
</list>
</query>
</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>
<example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg2'>
@ -476,7 +476,7 @@
</list>
</query>
</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>
<example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg3'>
@ -491,7 +491,7 @@
</list>
</query>
</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>
<example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='msg4'>
@ -503,7 +503,7 @@
</list>
</query>
</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>
</section2>
<section2 topic="Blocking Inbound Presence Notifications" anchor="protocol-presencein">
@ -522,7 +522,7 @@
</list>
</query>
</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>
<example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin2'>
@ -537,7 +537,7 @@
</list>
</query>
</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>
<example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin3'>
@ -552,7 +552,7 @@
</list>
</query>
</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>
<example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presin4'>
@ -564,7 +564,7 @@
</list>
</query>
</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>Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.</p>
</section2>
@ -584,7 +584,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.</p>
<example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout2'>
@ -599,7 +599,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout3'>
@ -614,7 +614,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='presout4'>
@ -626,7 +626,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
<p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
</section2>
@ -645,7 +645,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.</p>
<example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq2'>
@ -660,7 +660,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq3'>
@ -675,7 +675,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='iq4'>
@ -687,7 +687,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.</p>
</section2>
<section2 topic="Blocking All Communication" anchor="protocol-all">
@ -703,7 +703,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.</p>
<example caption='User blocks based on roster group'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all2'>
@ -716,7 +716,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.</p>
<example caption='User blocks based on subscription type'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all3'>
@ -729,7 +729,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.</p>
<example caption='User blocks globally'><![CDATA[
<iq from='romeo@example.net/orchard' type='set' id='all4'>
@ -739,7 +739,7 @@
</list>
</query>
</iq>
]]></example>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.</p>
</section2>
<section2 topic="Blocked Entity Attempts to Communicate with User" anchor="protocol-error">
@ -757,7 +757,7 @@
id='probing1'>
<query xmlns='jabber:iq:version'/>
</iq>
]]></example>
]]></example>
<example caption='Server returns error to blocked entity'><![CDATA[
<iq type='error'
from='romeo@example.net'
@ -769,7 +769,7 @@
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
]]></example>
<p>If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a &notacceptable; error:</p>
<example caption='Error: contact is blocked'><![CDATA[
<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'/>
</error>
</message>
]]></example>
]]></example>
</section2>
<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>
@ -801,7 +801,7 @@
</list>
</query>
</iq>
]]></code>
]]></code>
</section2>
</section1>
@ -814,7 +814,7 @@
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
]]></example>
<example caption="Service Discovery information response"><![CDATA[
<iq from='example.com'
id='disco1'
@ -826,7 +826,7 @@
...
</query>
</iq>
]]></example>
]]></example>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
@ -962,7 +962,7 @@
</xs:simpleType>
</xs:schema>
]]></code>
]]></code>
</section1>
<section1 topic='Author Note' anchor='authornote'>

12
xep-0020.xml
View File

@ -120,7 +120,7 @@
</x>
</feature>
</iq>
]]></example>
]]></example>
<example caption="Responding entity sends preferred option values"><![CDATA[
<iq type='result'
id='neg1'
@ -140,7 +140,7 @@
</x>
</feature>
</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>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[
@ -160,7 +160,7 @@
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
<example caption="Responding entity does not support a feature"><![CDATA[
<iq type='error'
@ -180,7 +180,7 @@
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>times-to-meet</text>
</error>
</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>
<example caption="Responding entity supports no options"><![CDATA[
<iq type='error'
@ -200,7 +200,7 @@
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>places-to-meet</text>
</error>
</iq>
]]></example>
]]></example>
</section2>
<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>
@ -314,7 +314,7 @@
</xs:element>
</xs:schema>
]]></code>
]]></code>
</section1>
<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>

26
xep-0022.xml
View File

@ -121,7 +121,7 @@
<composing/>
</x>
</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>Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.</p>
</section2>
@ -137,7 +137,7 @@
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p>
<ul>
<li>The element must contain only a jabber:x:event extension. Standard message elements such as &lt;subject/&gt;, &lt;body/&gt;, MUST NOT be included.</li>
@ -160,7 +160,7 @@
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<example caption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[
<message
from='romeo@montague.net'
@ -169,7 +169,7 @@
<id>message22</id>
</x>
</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>
</section2>
</section1>
@ -186,7 +186,7 @@ SEND: <message to='romeo@montague.net' id='message22'>
<composing/>
</x>
</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>
<example caption='Receiving the offline event'><![CDATA[
RECV: <message
@ -197,7 +197,7 @@ RECV: <message
<id>message22</id>
</x>
</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>
<example caption='Juliet receives notification of message delivery'><![CDATA[
RECV: <message
@ -208,7 +208,7 @@ RECV: <message
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<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[
RECV: <message
@ -219,7 +219,7 @@ RECV: <message
<id>message22</id>
</x>
</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>
<example caption='Juliet receives notification of message composing'><![CDATA[
RECV: <message
@ -230,7 +230,7 @@ RECV: <message
<id>message22</id>
</x>
</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>
<example caption='Juliet receives cancellation of message composing'><![CDATA[
RECV: <message
@ -240,7 +240,7 @@ RECV: <message
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<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[
RECV: <message
@ -251,7 +251,7 @@ RECV: <message
<id>message22</id>
</x>
</message>
]]></example>
]]></example>
<p>Romeo finally sends his reply, and requests composing events related to it.</p>
<example caption='Romeo replies'><![CDATA[
SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
@ -260,7 +260,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<composing/>
</x>
</message>
]]></example>
]]></example>
</section1>
<section1 topic='Implementation Notes'>
@ -319,7 +319,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
</xs:simpleType>
</xs:schema>
]]></code>
]]></code>
</section1>
<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:schema>
]]></code>
]]></code>
</section1>
<section1 topic='Open Issues'>

4
xep-0027.xml
View File

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

68
xep-0030.xml
View File

@ -276,7 +276,7 @@
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</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>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>