moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2025-03-02 17:41:47 -05:00
Code Issues Releases Wiki Activity

Remove all trailing whitespace from every XEP.

Browse Source 
sed -i 's/\s\+$//' xep-*.xml
This commit is contained in:
Emmanuel Gil Peyrot 2017-02-14 22:10:01 +00:00 committed by Sam Whited
parent 856c7427d6
commit 3c5f20a4ca
239 changed files with 4021 additions and 4021 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
xep-0001.xml
View File

@ -211,7 +211,7 @@
<ol start='1'>
<li>To produce practical, technically excellent solutions to important problems of real-time communication based on the set of streaming XML technologies known as XMPP.</li>
<li>To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
<li>To ensure interoperability among the disparate technologies used on XMPP networks.</li>
<li>To ensure interoperability among the disparate technologies used on XMPP networks.</li>
<li>To guarantee that any person or entity can implement the protocols without encumbrance.</li>
<li>To work in an fair, open, objective manner.</li>
</ol>
@ -350,8 +350,8 @@ Experimental ----> Proposed ----> Active
|
+--> Obsolete
</code>
<p>Because such XEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the XMPP Council. However, some of these XEPs may be remanded from the Council to the XEP author and/or XMPP Extensions Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track XEPs, the XEP author may retract such a XEP when it is Experimental, and the Council may reject such a XEP when it is Proposed.</p>
<p>Once approved, Historical, Informational, and Procedural XEPs will have a status of Active. Such a XEP may be replaced by a new XEP on the same or a similar topic, thus rendering the earlier XEP out of date; in such cases, the earlier XEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding XEP.</p>
<p>Because such XEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the XMPP Council. However, some of these XEPs may be remanded from the Council to the XEP author and/or XMPP Extensions Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track XEPs, the XEP author may retract such a XEP when it is Experimental, and the Council may reject such a XEP when it is Proposed.</p>
<p>Once approved, Historical, Informational, and Procedural XEPs will have a status of Active. Such a XEP may be replaced by a new XEP on the same or a similar topic, thus rendering the earlier XEP out of date; in such cases, the earlier XEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding XEP.</p>
<p>The XMPP Council may, at its discretion, decide to convert an Historical XEP into a Standards Track XEP if the protocol defined in the XEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical XEP shall be treated in the same way as a Standards Track XEP that has a status of Experimental, beginning with the <link url="#proposal">Proposal Process</link>. If after the Last Call and voting by the XMPP Council the XEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.</p>
</section2>
</section1>
@ -370,7 +370,7 @@ Experimental ----> Proposed ----> Active
</section2>
<section2 topic='Final' anchor='states-Final'>
<p>A Standards Track XEP is in the Final state after it has been in the Draft state for at least six (6) months, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
</section2>
<section2 topic='Active' anchor='states-Active'>
<p>A XEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the XMPP Council.</p>
@ -453,10 +453,10 @@ THE SOFTWARE.
<xs:annotation>
<xs:documentation>
This schema defines the document format for XMPP Extension
This schema defines the document format for XMPP Extension
Protocols (XEPs). For further information about XEPs, visit:
http://www.xmpp.org/extensions/
http://www.xmpp.org/extensions/
The canonical URL for this schema is:
@ -481,20 +481,20 @@ THE SOFTWARE.
<xs:element name='number' type='xs:byte'/>
<xs:element ref='status'/>
<xs:element name='lastcall' minOccurs='0' type='xs:string'/>
<xs:element name='interim' minOccurs='0' type='empty'/>
<xs:element ref='type'/>
<xs:element name='interim' minOccurs='0' type='empty'/>
<xs:element ref='type'/>
<xs:element name='sig' type='xs:string'/>
<xs:element name='approver' type='xs:string'/>
<xs:element ref='dependencies'/>
<xs:element ref='supersedes'/>
<xs:element ref='supersededby'/>
<xs:element name='shortname' type='xs:NCName'/>
<xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
<xs:element name='registry' minOccurs='0' type='empty'/>
<xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
<xs:element name='registry' minOccurs='0' type='empty'/>
<xs:element name='discuss' minOccurs='0' type='xs:string'/>
<xs:element name='expires' minOccurs='0' type='xs:string'/>
<xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
<xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
<xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
<xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
@ -744,7 +744,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='source' use='required'/>
<xs:attribute name='source' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@ -754,7 +754,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='url' use='required'/>
<xs:attribute name='url' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@ -766,7 +766,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='caption' use='optional'/>
<xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@ -776,7 +776,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='caption' use='optional'/>
<xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@ -804,8 +804,8 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@ -815,8 +815,8 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

16
xep-0004.xml
View File

@ -317,7 +317,7 @@
type='get'
xml:lang='en'
id='create1'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='create'
action='execute'/>
</iq>
@ -481,7 +481,7 @@
type='get'
xml:lang='en'
id='search1'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='search'
action='execute'/>
</iq>
@ -492,7 +492,7 @@
type='result'
xml:lang='en'
id='search1'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='search'
status='executing'>
<x xmlns='jabber:x:data' type='form'>
@ -512,7 +512,7 @@
type='get'
xml:lang='en'
id='search2'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='search'>
<x xmlns='jabber:x:data' type='submit'>
<field type='text-single' var='search_request'>
@ -528,7 +528,7 @@
type='result'
xml:lang='en'
id='search2'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='search'
status='completed'>
<x xmlns='jabber:x:data' type='result'>
@ -642,9 +642,9 @@
<xs:element name='x'>
<xs:complexType>
<xs:sequence>
<xs:element name='instructions'
minOccurs='0'
maxOccurs='unbounded'
<xs:element name='instructions'
minOccurs='0'
maxOccurs='unbounded'
type='xs:string'/>
<xs:element name='title' minOccurs='0' type='xs:string'/>
<xs:element ref='field' minOccurs='0' maxOccurs='unbounded'/>

2
xep-0007.xml
View File

@ -70,7 +70,7 @@
<li>The "groupchat" protocol has no way of performing feature negotiation (e.g., specifying the additional protocol elements needed to participate in a room, or optionally allowed from participants within a room). If there were participants with clients sending custom data through the room (such as XHTML or whiteboarding), you would receive that information even without your client being able to support it, and have no way of distinguishing altered behavior due to additional features of a "groupchat" implementation.</li>
</ul>
<p>This new conferencing protocol will be designed to solve these problems.</p>
<p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p>
<p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p>
</section1>
<section1 topic='Continuing Development'>
<p>As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.</p>

58
xep-0009.xml
View File

@ -5,7 +5,7 @@
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<header>
<title>Jabber-RPC</title>
<abstract>This specification defines an XMPP protocol extension for transporting XML-RPC encoded requests and responses between two XMPP entities. The protocol supports all syntax and semantics of XML-RPC except that it uses XMPP instead of HTTP as the underlying transport.</abstract>
&LEGALNOTICE;
@ -74,9 +74,9 @@
</section1>
<section1 topic='Examples'>
<example caption='A typical request'><![CDATA[
<iq type='set'
from='requester@company-b.com/jrpc-client'
to='responder@company-a.com/jrpc-server'
<iq type='set'
from='requester@company-b.com/jrpc-client'
to='responder@company-a.com/jrpc-server'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodCall>
@ -91,9 +91,9 @@
</iq>
]]></example>
<example caption='A typical response'><![CDATA[
<iq type='result'
from='responder@company-a.com/jrpc-server'
to='requester@company-b.com/jrpc-client'
<iq type='result'
from='responder@company-a.com/jrpc-server'
to='requester@company-b.com/jrpc-client'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodResponse>
@ -108,9 +108,9 @@
]]></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'
from='responder@company-a.com/jrpc-server'
to='requester@company-b.com/jrpc-client'
<iq type='error'
from='responder@company-a.com/jrpc-server'
to='requester@company-b.com/jrpc-client'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodCall>
@ -131,17 +131,17 @@
<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>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='requester@company-b.com/jrpc-client'
to='responder@company-a.com/jrpc-server'
<iq type='get'
from='requester@company-b.com/jrpc-client'
to='responder@company-a.com/jrpc-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
to='requester@company-b.com/jrpc-client'
from='responder@company-a.com/jrpc-server'
<iq type='result'
to='requester@company-b.com/jrpc-client'
from='responder@company-a.com/jrpc-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='rpc'/>
@ -179,9 +179,9 @@
The protocol documented by this schema is defined in
XEP-0009: http://www.xmpp.org/extensions/xep-0009.html
There is no official XML schema for XML-RPC. The main body
of this schema has been borrowed from an unofficial schema
representation contained in the book "Processing XML With
There is no official XML schema for XML-RPC. The main body
of this schema has been borrowed from an unofficial schema
representation contained in the book "Processing XML With
Java" by Elliotte Rusty Harold, as located at:
http://www.ibiblio.org/xml/books/xmljava/chapters/ch02s05.html
@ -210,13 +210,13 @@
<xs:element name="params" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" type="ParamType"
<xs:element name="param" type="ParamType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:complexType>
</xs:element>
<xs:element name="methodResponse">
@ -236,13 +236,13 @@
<xs:element name="value">
<xs:complexType>
<xs:sequence>
<xs:element name="struct">
<xs:complexType>
<xs:sequence>
<xs:element name="member"
<xs:element name="struct">
<xs:complexType>
<xs:sequence>
<xs:element name="member"
type="MemberType">
</xs:element>
<xs:element name="member"
<xs:element name="member"
type="MemberType">
</xs:element>
</xs:sequence>
@ -255,7 +255,7 @@
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:complexType>
</xs:element>
<xs:complexType name="ParamType">
@ -286,7 +286,7 @@
<xs:complexType name="StructType">
<xs:sequence>
<xs:element name="member" type="MemberType"
<xs:element name="member" type="MemberType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
@ -303,7 +303,7 @@
<xs:element name="data">
<xs:complexType>
<xs:sequence>
<xs:element name="value" type="ValueType"
<xs:element name="value" type="ValueType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>

24
xep-0012.xml
View File

@ -81,7 +81,7 @@
<section1 topic='Protocol' anchor='protocol'>
<p>In order to request last activity information regarding another entity, the requesting entity sends an &IQ; stanza of type "get" to the target entity, containing a &QUERY; element qualified by the 'jabber:iq:last' namespace:</p>
<example caption='Last Activity Query'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='last1'
to='juliet@capulet.com'
type='get'>
@ -90,7 +90,7 @@
]]></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'
<iq from='juliet@capulet.com'
id='last1'
to='romeo@montague.net/orchard'
type='result'>
@ -108,7 +108,7 @@
<section1 topic='Offline User Query' anchor='offline'>
<p>The primary usage of the 'jabber:iq:last' namespace is to find out how long ago a user logged out (and, additionally, what their status message was at that time). This primary usage assumes that the IQ-get is sent to a bare JID &LOCALBARE;. When used in this way, the &QUERY; element contained in the IQ-result has a 'seconds' attribute, which is the number of seconds that have passed since the user last logged out. In addition, the element MAY contain XML character data that specifies the status message of the last unavailable presence received from the user. An example is shown below:</p>
<example caption='Last Activity Query'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='last1'
to='juliet@capulet.com'
type='get'>
@ -118,9 +118,9 @@
<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[
<iq from='juliet@capulet.com'
<iq from='juliet@capulet.com'
id='last1'
to='romeo@montague.net/orchard'
to='romeo@montague.net/orchard'
type='error'>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -152,7 +152,7 @@
<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[
<iq from='juliet@capulet.com'
<iq from='juliet@capulet.com'
id='last1'
to='romeo@montague.net/orchard'
type='error'>
@ -163,9 +163,9 @@
]]></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'
<iq from='juliet@capulet.com/balcony'
id='last2'
to='romeo@montague.net/orchard'
to='romeo@montague.net/orchard'
type='result'>
<query xmlns='jabber:iq:last' seconds='123'/>
</iq>
@ -173,7 +173,7 @@
<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[
<iq from='juliet@capulet.com/balcony'
<iq from='juliet@capulet.com/balcony'
id='last2'
to='romeo@montague.net/orchard'
type='error'>
@ -187,15 +187,15 @@
<section1 topic='Server and Component Query' anchor='server'>
<p>When the last activity query is sent to a server or component (i.e., to a JID of the form &DOMAINBARE;), the information contained in the IQ reply reflects the uptime of the JID sending the reply. The seconds attribute specifies how long the host has been running since it was last (re-)started. The &QUERY; element SHOULD NOT contain XML character data.</p>
<example caption='Last Activity Query Sent to Server or Service'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='last3'
to='capulet.com'
to='capulet.com'
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
]]></example>
<example caption='Last Activity Response from Server or Service'><![CDATA[
<iq from='capulet.com'
<iq from='capulet.com'
id='last3'
to='romeo@montague.net/orchard'
type='result'>

32
xep-0013.xml
View File

@ -122,12 +122,12 @@
<p>In order to discover whether one's server supports this protocol, one uses &xep0030;.</p>
<example caption='User Requests Service Discovery Information'><![CDATA[
<iq type='get' to='montague.net'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='Server Reply to Discovery Request'><![CDATA[
<iq type='result'
from='montague.net'
<iq type='result'
from='montague.net'
to='romeo@montague.net/orchard'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jabber.org/protocol/offline'/>
@ -141,7 +141,7 @@
<p>In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline':</p>
<example caption='User Requests Information About Offline Message Node'><![CDATA[
<iq type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/offline'/>
</iq>
]]></example>
@ -171,32 +171,32 @@
<p>In order to retrieve headers for all of the messages in the queue, the user sends a disco#items request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline'.</p>
<example caption='User Requests Offline Message Headers'><![CDATA[
<iq type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'/>
</iq>
]]></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'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'>
<item
<item
jid='romeo@montague.net'
node='2003-02-27T22:49:17.008Z'
name='mercutio@shakespeare.lit/pda'/>
<item
<item
jid='romeo@montague.net'
node='2003-02-27T22:52:37.225Z'
name='juliet@capulet.com/balcony'/>
<item
<item
jid='romeo@montague.net'
node='2003-02-27T22:52:51.270Z'
name='juliet@capulet.com/balcony'/>
<item
<item
jid='romeo@montague.net'
node='2003-02-27T22:53:03.421Z'
name='juliet@capulet.com/balcony'/>
<item
<item
jid='romeo@montague.net'
node='2003-02-27T22:53:13.925Z'
name='juliet@capulet.com/balcony'/>
@ -298,7 +298,7 @@ S: <stream:stream ...>
C: authentication (SASL in XMPP, non-SASL in older systems)
S: acknowledge successful authentication
S: acknowledge successful authentication
C: <presence/>
@ -315,7 +315,7 @@ S: <stream:stream ...>
C: authentication (SASL in XMPP, non-SASL in older systems)
S: acknowledge successful authentication
S: acknowledge successful authentication
C: request message headers
@ -325,7 +325,7 @@ NOTE: Server now MUST NOT flood Client with offline messages.
C: <presence/>
NOTE: Server does not flood Client with offline messages, but
NOTE: Server does not flood Client with offline messages, but
sends in-session messages as usual.
C: request and remove offline messages, send and receive messages, etc.
@ -363,7 +363,7 @@ C: request and remove offline messages, send and receive messages, etc.
<type>
<name>message-list</name>
<desc>
The node for the offline message queue; valid only for the node
The node for the offline message queue; valid only for the node
"http://jabber.org/protocol/offline"
</desc>
<doc>XEP-0013</doc>
@ -371,7 +371,7 @@ C: request and remove offline messages, send and receive messages, etc.
<type>
<name>message-node</name>
<desc>
A node for a specific offline message if service discovery is
A node for a specific offline message if service discovery is
provided for messages
</desc>
<doc>XEP-0013</doc>

2
xep-0018.xml
View File

@ -119,7 +119,7 @@
<example caption="Server forwards presence update to stpeter@foo.com and rynok@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="stpeter@foo.com">
<show>chat</show>
</presence>
<presence from="joe@foo.com/resource" to="rynok@foo.com/resource">
<show>chat</show>
</presence>]]></example>

2
xep-0019.xml
View File

@ -52,7 +52,7 @@
<ol>
<li>"Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
<li>"Wait and see" -- immediately disband the SIGs that are clearly inactive but keep the existing SIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).</li>
<li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.</li>
<li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.</li>
</ol>
<p>Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.</p>
<p>But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.</p>

14
xep-0021.xml
View File

@ -48,14 +48,14 @@
<li>User's avatar has changed</li>
<li>The coffee machine is empty</li>
</ul>
<p>In Jabber, the role of the ENS has traditionally been filled by overloading the &lt;presence/&gt; packet type. However, this method was never designed to be used as a general publish-and-subscribe mechanism, and so has the following problems:</p>
<ul>
<li>Dispatching of &lt;presence/&gt; packets is performed by the JSM (Jabber Session Manager), and so is not easily usable by components and other entities that don't connect via a client manager (c2s, CCM).</li>
<li>An entity cannot subscribe to the presence of a specific resource of another entity, only to any presence from that entity. This lack of granularity makes its difficult to use &lt;presence/&gt; in situations where large chunks of data must be dispatched to subscribers (eg avatars).</li>
</ul>
<p>The protocol consists of two parts - the subscriber-to-ENS protocol, and the publisher-to-ENS protocol. Since there is no direct interaction between a publisher and a subscriber, it makes sense to seperate the two parts of the protocol.</p>
<p>The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.</p>
@ -187,7 +187,7 @@
</example>
<p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
<example caption='Event notification (publish) with payload'>
&lt;iq id='enspub2' type='set' from='ens-jid' to='subscriber-jid'&gt;
&lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'&gt;
@ -225,7 +225,7 @@
</example>
<p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
<example caption='Event notification (publish) with payload'>
&lt;iq id='pub1' type='set' from='event-jid' to='ens-jid'&gt;
&lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/'&gt;
@ -257,7 +257,7 @@
</example>
<p>The subscriber may include an &lt;auth-info/&gt; XML fragment containing some (application-specific) information that the publisher can use to authorise it:</p>
<example caption='Authorisation request with authorisation information'>
&lt;iq id='ensauth1' type='get' from='ens-jid' to='event-jid'&gt;
&lt;authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'&gt;
@ -270,7 +270,7 @@
<section2 topic='Authorisation response'>
<p>To signal to the ENS that a subscriber should be allowed to subscribe, the publisher should return a packet of the following form:</p>
<example caption='Successful authorisation response'>
&lt;iq id='ensauth1' type='result' from='event-jid' to='ens-jid'&gt;
&lt;authorised xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/&gt;
@ -310,7 +310,7 @@
<li>Have some sort of ENS-to-ENS protocol, and have ENSs proxy publishes for other ENSs. This does not fix the problem, it just moves it away from the subscriber and into the ENS. An ENS will still need to find out which ENS the publisher is publishing to.</li>
<li>Integrate ENS into the session manager. This leaves us with a glorified presence system, and makes the ENS basically unusable by non-session-manager-based server components.</li>
</ul>
<p>This problem may be outside of the scope of this specification.</p>
</section2>

96
xep-0024.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Publish/Subscribe</title>
<abstract>A publish-subscribe protocol for Jabber.</abstract>
<abstract>A publish-subscribe protocol for Jabber.</abstract>
&PUBLICDOMAINNOTICE;
<number>0024</number>
<status>Retracted</status>
@ -64,7 +64,7 @@ two separate but related goals:
<p>
The specification details the use of the Jabber protocol elements and
introduces a new namespace, jabber:iq:pubsub.
introduces a new namespace, jabber:iq:pubsub.
It also includes notes on actual implementation of such a
mechanism in Jabber.
</p>
@ -78,7 +78,7 @@ It's clear that as Jabber is deployed over a wider spectrum of platforms
and circumstances, more and more information will be exchanged. Whether
that information is specific to Jabber (JSM) users, or components, we need
an mechanism to be able to manage the exchange of this information in an
efficient way.
efficient way.
</p>
<p>
@ -301,7 +301,7 @@ You can also send an unsubscribe without specifying any namespaces:
</p>
<example caption='Publisher-specific general unsubscription'>
SEND: &lt;iq type='set' to='pubsub.localhost'
SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe to='publisher'/&gt;
@ -392,7 +392,7 @@ Likewise, you can unsubscribe from certain namespaces in this non-publisher-spec
</p>
<example caption='General unsubscription to specific namespaces'>
SEND: &lt;iq type='set' to='pubsub.localhost'
SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe&gt;
@ -402,7 +402,7 @@ SEND: &lt;iq type='set' to='pubsub.localhost'
&lt;/query&gt;
&lt;/iq&gt;
RECV: &lt;iq type='result' from='pubsub.localhost'
RECV: &lt;iq type='result' from='pubsub.localhost'
to='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe&gt;
@ -424,14 +424,14 @@ Finally, a subscriber can wipe the slate clean like this:
</p>
<example caption='Wiping the slate'>
SEND: &lt;iq type='set' to='pubsub.localhost'
SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe/&gt;
&lt;/query&gt;
&lt;/iq&gt;
RECV: &lt;iq type='result' from='pubsub.localhost'
RECV: &lt;iq type='result' from='pubsub.localhost'
to='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe/&gt;
@ -644,7 +644,7 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
<!--
<p>
Optionally, a pubsub component may respond with an empty IQ-result, to
Optionally, a pubsub component may respond with an empty IQ-result, to
reduce traffic:
</p>
@ -657,13 +657,13 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
<p>
Each published item is wrapped in a &lt;publish/&gt; tag. This tag
must contain the namespace of the item being publishes, in an ns
must contain the namespace of the item being publishes, in an ns
attribute, as shown. This is distinct from the xmlns attribute of
the fragment of XML actually being published. It is theoretically
none of the pubsub component's business to go poking around in the
real published data, nor should it have to. It needs to know what
namespace is qualifying the published information that has been
received, so that the list of appropriate recipients can be
namespace is qualifying the published information that has been
received, so that the list of appropriate recipients can be
determined.
</p>
@ -674,7 +674,7 @@ determined.
<p>
While it's the responsibility of the publishing entities to publish
information, it's the responsibility of the pubsub
component to push out that published data to the subscribers. The
component to push out that published data to the subscribers. The
list of recipient subscribers must be determined by the information
stored by the pubsub component as a result of receiving subscription
requests (which are described earlier).
@ -694,7 +694,7 @@ fragments of published data.</note>
<p>
Taking the earlier example of the publishing of data in the 'foo'
namespace, the following example shows what the pubsub component
must send to push this foo data out to a subscriber.
must send to push this foo data out to a subscriber.
</p>
<example caption='Pushing out published information to a subscriber'>
SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
@ -707,7 +707,7 @@ SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
&lt;/iq&gt;
</example>
<p>
The recipient is _not_ required to send an 'acknowledgement' in the
The recipient is _not_ required to send an 'acknowledgement' in the
form of an IQ-result; the idea that this _push_ of information is
akin to how information is pushed in a live browsing context (see
jabber:iq:browse documentation for more details).
@ -720,7 +720,7 @@ jabber:iq:browse documentation for more details).
<p>
When a pubsub service receives a publish packet like the ones above, it
needs to deliver (push) the information out according to the subscriptions
that have been made.
that have been made.
</p>
<p>
@ -729,7 +729,7 @@ subscription between the pubsub service and the subscriber(s). If the
subscriber wishes only to receive information when he's online (this is
a JSM-specific issue), then he needs to set up a presence subscription
relationship with the pubsub service. The pubsub service should respond
to presence subscriptions and unsubscriptions by
to presence subscriptions and unsubscriptions by
</p>
<ul>
@ -740,16 +740,16 @@ to presence subscriptions and unsubscriptions by
<p>
If the pubsub service deems that a published piece of information should
be pushed to a subscriber, and there is a presence subscription relationship
with that subscriber, the service should only push that information to the
with that subscriber, the service should only push that information to the
subscriber if he is available. If he is not available, the information is not
to be sent.
to be sent.
</p>
<p>
Thus the subscriber can control the sensitivity by initiating (or not) a
presence relationship with the service. If the subscriber wishes to receive
information regardless of availability, he should not initiate a (or cancel
any previous) presence relationship with the service.
any previous) presence relationship with the service.
</p>
<p>
@ -762,7 +762,7 @@ publish/subscribe where presence is not a given.
<section2 topic='Use of Resources'>
<p>
When in receipt of a pubsub subscription request from an entity
When in receipt of a pubsub subscription request from an entity
where a resource is specified in the JID, the pubsub component must
honour the resource specified in the from attribute of the request.
For example, here's a typical subscription request from a JSM user:
@ -780,7 +780,7 @@ RECV: &lt;iq type='set' to='pubsub.localhost'
</example>
<p>
When storing the subscriber/publisher/namespace relationship matrix for
eventual querying when a publisher publishes some information, the
eventual querying when a publisher publishes some information, the
pubsub component must use the full JID, not just the username@host part.
</p>
<p>
@ -802,7 +802,7 @@ the full JID of the component subscriber - news.server/politics-listener,
should be used to qualify the matrix.
</p>
<p>
This is because it allows the subscribing entities to arrange the
This is because it allows the subscribing entities to arrange the
receipt of pushed items by resource. In the case of a JSM user, it
allows him to organise his clients, which may have different capabilities
(some being able to handle the jabber:iq:pubsub data, others not) to
@ -828,11 +828,11 @@ the main ones are discussed briefly here too.
<section2 topic='Publisher Discovery'>
<p>
There is no part of this pubsub specification that determines how a
There is no part of this pubsub specification that determines how a
potential subscriber might discover publishers. After all, there are
no rules governing which pubsub component a publisher could or should
publish to. And since pubsub subscriptions are specific to a pubsub
component, there is an information gap - "how do I find out what
component, there is an information gap - "how do I find out what
publishers there are, and through which pubsub components they're publishing
information?"
</p>
@ -857,7 +857,7 @@ here). The next two sections look at how these things might pan out.
<section2 topic='Cross-Server Relationships'>
<p>
When JSM users on server1 wish to subscribe to information published
When JSM users on server1 wish to subscribe to information published
by JSM users on server2 (let's say it's the mp3 player info, or avatars)
then there are some issues that come immediately to mind:
</p>
@ -865,9 +865,9 @@ then there are some issues that come immediately to mind:
<li>Does a JSM user on server1 (userA@server1) send his IQ-set subscription
to the pubsub component on server2 (pubsub.server2), or server1
(pubsub.server1)?</li>
<li>If he sends it to pubsub.server2, can we expect
pubsub.server2 to always accept that subscription request, i.e. to
be willing to serve userA@server1 (if pubsub.server2 knows that
<li>If he sends it to pubsub.server2, can we expect
pubsub.server2 to always accept that subscription request, i.e. to
be willing to serve userA@server1 (if pubsub.server2 knows that
pubsub.server1 exists)?</li>
<li>Will there be performance (or at least server-to-server traffic)
implications if many subscription relationships exist between subscribers on
@ -876,7 +876,7 @@ server1 and publishers on server2?</li>
<section3 topic='Proxy Subscriptions'>
<p>
To reduce the amount of server-to-server traffic, we can employ the
To reduce the amount of server-to-server traffic, we can employ the
concept of "proxy subscriptions". This is simply getting a pubsub component
to act on behalf of a (server-local) subscriber. Benefit comes when a pubsub
component acts on behalf of multiple (server-local) subscribers.
@ -889,7 +889,7 @@ server-to-server traffic:
Step 1: Subscriber sends original subscription
</p>
<p>
JSM users on server1 wish to subscribe to information published by an
JSM users on server1 wish to subscribe to information published by an
entity on server2. Each of them sends a subscription request to the
_local_ pubsub component:
</p>
@ -925,7 +925,7 @@ SEND: &lt;iq type='set' to='pubsub.server2'
<p>
The remote pubsub component receives and acknowledges the subscription
request, and the local pubsub component relays the response back to
request, and the local pubsub component relays the response back to
the original requester:
</p>
<example>
@ -940,7 +940,7 @@ SEND: &lt;iq type='result' from='pubsub.server1'
</example>
<p>
If the remote pubsub server was unable or unwilling to accept the
If the remote pubsub server was unable or unwilling to accept the
subscription request, this should be reflected in the response:
</p>
<example>
@ -959,7 +959,7 @@ SEND: &lt;iq type='error' from='pubsub.server1'
Step3: Publisher publishes information
</p>
<p>
The publisher, publisher.server2, publishes information in the
The publisher, publisher.server2, publishes information in the
namespace:1 namespace, to the remote pubsub component pubsub.server2:
</p>
<example>
@ -1022,18 +1022,18 @@ where publisher entities publish their information.
This knowledge, and the mechanisms to discover this sort of information,
is not to be covered in this spec, which purely deals with the subscription
and publishing of information. As SOAP is to UDDI (to use a slightly
controversial pair of technologies), so is jabber:iq:pubsub to this
controversial pair of technologies), so is jabber:iq:pubsub to this
discovery mechanism as yet undefined. To include the definition of such
a discovery mechanism in this specification is wrong on two counts:
</p>
<ul>
<li>Discovery mechanisms by nature should not be tied to specific areas</li>
<li>Trying to load too much onto jabber:iq:pubsub will only produce a
<li>Trying to load too much onto jabber:iq:pubsub will only produce a
complex and hard-to-implement specification</li>
</ul>
<p>
After all, the jabber:iq:pubsub spec as defined here is usable out of the
box for the simple scenarios, and scenarios where discovery is not
box for the simple scenarios, and scenarios where discovery is not
necessary or the information can be exchanged in other ways.
</p>
@ -1042,7 +1042,7 @@ necessary or the information can be exchanged in other ways.
<section3 topic='Willingness to Serve'>
<p>
There are some situations where it might be appropriate for a pubsub
component to refuse particular subscription requests. Here are two
component to refuse particular subscription requests. Here are two
examples:
</p>
<ul>
@ -1051,11 +1051,11 @@ configured to handle local-only pubsub traffic, and a subscription request
is received, specifying a publisher that the local pubsub component knows
to be one that publishes to a remote pubsub component <note>under other
circumstances, this would trigger a 'Proxy Subscription', as described earlier, if supported</note>. In this case, the local pubsub component would be
unwilling to provoke a server-to-server connection and therefore unwilling to
unwilling to provoke a server-to-server connection and therefore unwilling to
honour the request.</li>
<li>Where a pubsub component receives a subscription request from a
remote subscriber, and that pubsub component knows that there's a
pubsub component local to the subscriber. In this case, the (administrator
<li>Where a pubsub component receives a subscription request from a
remote subscriber, and that pubsub component knows that there's a
pubsub component local to the subscriber. In this case, the (administrator
of the) remote pubsub component might want to encourage proxy subscriptions.
</li>
</ul>
@ -1093,20 +1093,20 @@ but it's an interesting concept :-)</p>
<section2 topic='Subscriber Anonymity and Acceptance?'>
<p>
The jabber:iq:pubsub specification makes no provision for
The jabber:iq:pubsub specification makes no provision for
publishers to query a pubsub component to ask for a list of those entities
that are subscribed to (namespaces) it (publishes). This is deliberate.
that are subscribed to (namespaces) it (publishes). This is deliberate.
Do we wish to add to the specification to allow the publisher to discover
this information? If so, it must be as an optional 'opt-in' (or 'opt-out')
tag for the subscriber, to determine whether his JID will show up on the
list.
list.
<note>Even if there is no provision for querying the subscribers, perhaps
we should make a provision for the publisher to ask the pubsub component
for a list of namespaces that have been subscribed to (for that publisher).
</note>
</p>
<p>
Associated with this is the semi-reciprocal issue of acceptance? The
Associated with this is the semi-reciprocal issue of acceptance? The
specification deliberately makes no provision for a subscription acceptance
mechanism (where the publisher must first accept a subscriber's request,
via the pubsub component). If we're to prevent the publishers knowing
@ -1115,11 +1115,11 @@ things out'?
</p>
<p>
Note that if we do, the acceptance issue is not necessarily one for the
pubsub specification to resolve; there are other ways of introducing
pubsub specification to resolve; there are other ways of introducing
access control, at least in a component environment; use of a mechanism
that the Jabber::Component::Proxy Perl module represents is one example:
wedge a proxy component in front of a real (pubsub) component and have
the ability to use ACLs (access control lists) to control who gets to
the ability to use ACLs (access control lists) to control who gets to
connect to the real component.
</p>

6
xep-0025.xml
View File

@ -293,7 +293,7 @@
along with the last client request. If the values do not match, the
request should be ignored or logged, with an error code being
returned of -3:0. The request must not be processed, and must not
extend the session keepalive.
extend the session keepalive.
</li>
<li>
The client may send a new key K(m, seed') at any point, but should
@ -311,7 +311,7 @@ Host: webim.jabber.com
0,<stream:stream to="jabber.com"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">]]>
</example>
<example caption="Initial response">
@ -357,7 +357,7 @@ Host: webim.jabber.com
0;VvxEk07IFy6hUmG/PPBlTLE2fiA=,<stream:stream to="jabber.com"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">]]>
</example>
<example caption="Next request (with keys)">

16
xep-0026.xml
View File

@ -89,7 +89,7 @@
An xml:lang tag can be put onto any XML element; for the purposes of this document, however, we will limit its usage to the four central Jabber elements: &lt;stream/&gt;, &lt;message/&gt;, &lt;iq/&gt; and &lt;presence/&gt;.
</p>
</section2>
<section2 topic='Client support'>
<p>
A client claiming to support this document has to initiate server connection slightly differently by putting an xml:lang attribute in the initial &lt;stream:stream&gt; element.
@ -115,10 +115,10 @@
</p>
</section2>
<section2 topic='Server support'>
<p>
A compliant server must detect the xml:lang attribute in incoming &lt;stream:stream&gt; elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
A compliant server must detect the xml:lang attribute in incoming &lt;stream:stream&gt; elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
</p>
<p>
Additionally, a compliant server must attach an xml:lang attribute to the reply &lt;stream:stream&gt; element sent in response to a newly initiated connection. This attribute should reflect the default language of that server, and is used to indicate to clients that the server implements this document.
@ -134,7 +134,7 @@
</p>
</section2>
<section2 topic='Service support'>
<p>
Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on <cite>XEP-0004</cite>.
@ -152,7 +152,7 @@
&lt;x xmlns='jabber:x:data'&gt;
&lt;instructions&gt;
To search for a user fill out at least one
To search for a user fill out at least one
of the fields below and submit the form.
&lt;/instructions&gt;
&lt;field type='text-single' label='First (Given)' var='first'/&gt;
@ -179,7 +179,7 @@
&lt;iq from='users.jabber.org' type='result' id='5' xml:lang='de'&gt;
&lt;query xmlns='jabber:iq:search'&gt;
&lt;instructions&gt;
F&#252;llen Sie ein Feld aus um nach einem beliebigen
F&#252;llen Sie ein Feld aus um nach einem beliebigen
passenden Jabber-Benutzer zu suchen.
&lt;/instructions&gt;
&lt;nick/&gt;
@ -189,7 +189,7 @@
&lt;x xmlns='jabber:x:data'&gt;
&lt;instructions&gt;
Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines
Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines
der folgenden Felder aus und schicken dann das Formular ab.
&lt;/instructions&gt;
&lt;field type='text-single' label='Vorname' var='first'/&gt;
@ -202,7 +202,7 @@
<p>
If the component doesn't have the requested localization available, it replies with the default localization (but of course with the matching xml:lang attribute tagged to it, and not the one of the request).
</p>
</section2>
</section1>

22
xep-0029.xml
View File

@ -71,11 +71,11 @@
&lt;hname&gt; ::= &lt;let&gt;|&lt;dig&gt;[[&lt;let&gt;|&lt;dig&gt;|"-"]*&lt;let&gt;|&lt;dig&gt;]
&lt;let&gt; ::= [a-z] | [A-Z]
&lt;dig&gt; ::= [0-9]
&lt;conforming-char&gt; ::= #x21 | [#x23-#x25] | [#x28-#x2E] |
[#x30-#x39] | #x3B | #x3D | #x3F |
[#x41-#x7E] | [#x80-#xD7FF] |
&lt;conforming-char&gt; ::= #x21 | [#x23-#x25] | [#x28-#x2E] |
[#x30-#x39] | #x3B | #x3D | #x3F |
[#x41-#x7E] | [#x80-#xD7FF] |
[#xE000-#xFFFD] | [#x10000-#x10FFFF]
&lt;any-char&gt; ::= [#x20-#xD7FF] | [#xE000-#xFFFD] |
&lt;any-char&gt; ::= [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]
</code>
</section2>
@ -86,16 +86,16 @@
<p>Node identifiers are restricted to 256 bytes, They may contain any Unicode character higher than #x20 with the exception of the following:</p>
<ol>
<li>#x22 (")</li>
<li>#x26 (&amp;)</li>
<li>#x26 (&amp;)</li>
<li>#x27 (')</li>
<li>#x2F (/)</li>
<li>#x3A (:)</li>
<li>#x3C (&lt;)</li>
<li>#x3E (&gt;)</li>
<li>#x40 (@)</li>
<li>#x3A (:)</li>
<li>#x3C (&lt;)</li>
<li>#x3E (&gt;)</li>
<li>#x40 (@)</li>
<li>#x7F (del)</li>
<li>#xFFFE (BOM)</li>
<li>#xFFFF (BOM)</li>
<li>#xFFFE (BOM)</li>
<li>#xFFFF (BOM)</li>
</ol>
<p>Case is preserved, but comparisons will be made in case-normalized canonical form.</p>
</section2>

26
xep-0030.xml
View File

@ -410,7 +410,7 @@
from='romeo@montague.net/orchard'
to='mim.shakespeare.lit'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'/>
</iq>
]]></example>
@ -420,7 +420,7 @@
from='mim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'>
<identity
category='automation'
@ -538,7 +538,7 @@
from='romeo@montague.net/orchard'
to='catalog.shakespeare.lit'
id='items3'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='music'/>
</iq>
]]></example>
@ -548,7 +548,7 @@
from='catalog.shakespeare.lit'
to='romeo@montague.net/orchard'
id='items3'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='music'>
<item jid='catalog.shakespeare.lit'
node='music/A'/>
@ -570,7 +570,7 @@
from='romeo@montague.net/orchard'
to='catalog.shakespeare.lit'
id='items4'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='music/D'/>
</iq>
]]></example>
@ -579,7 +579,7 @@
from='catalog.shakespeare.lit'
to='romeo@montague.net/orchard'
id='items4'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='music/D'>
<item jid='catalog.shakespeare.lit'
node='music/D/dowland-firstbooke'
@ -613,17 +613,17 @@
id='items4'
to='romeo@montague.net'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'/>
</iq>
]]></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[
<iq from='romeo@montague.net'
id='items4'
to='juliet@capulet.com/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'>
<item jid='pubsub.shakespeare.lit'
name='Romeo&apos;s CD player'
@ -661,7 +661,7 @@
from='mim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'/>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -740,13 +740,13 @@
<category>
<name>hierarchy</name>
<desc>
An entity that exists in the context of a
An entity that exists in the context of a
service discovery node hierarchy.
</desc>
<type>
<name>branch</name>
<desc>
A "container node" for other entities in a
A "container node" for other entities in a
service discovery node hierarchy.
</desc>
<doc>XEP-0030</doc>
@ -754,7 +754,7 @@
<type>
<name>leaf</name>
<desc>
A "terminal node" in a service discovery
A "terminal node" in a service discovery
node hierarchy.
</desc>
<doc>XEP-0030</doc>

532
xep-0031.xml
View File

File diff suppressed because it is too large Load Diff

14
xep-0032.xml
View File

@ -67,10 +67,10 @@
</section2>
<section2 topic='Node Identifier Component'>
<p>The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of XEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:</p>
<code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
<code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
<p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
<p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
<code>#x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)</code>
<p>Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:</p>
<code>#x23 (#) | #x25 (%)</code>
@ -82,10 +82,10 @@
</section2>
<section2 topic='Query Component'>
<p>The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:</p>
<code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) |
#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) |
#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) |
<code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) |
#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) |
#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
</section2>
</section1>

32
xep-0033.xml
View File

@ -6,7 +6,7 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Extended Stanza Addressing</title>
<title>Extended Stanza Addressing</title>
<abstract>This specification defines an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
&LEGALNOTICE;
<number>0033</number>
@ -55,7 +55,7 @@
<version>0.10</version>
<date>2004-03-18</date>
<initials>psa</initials>
<remark>Disallowed &lt;addresses/&gt; as direct child
<remark>Disallowed &lt;addresses/&gt; as direct child
of &IQ;.</remark>
</revision>
@ -143,12 +143,12 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>On the existing Jabber network, there are many opportunities to optimize stanza traffic. For example, clients that want to send the same stanza to multiple recipients currently must send multiple stanzas. Similarly, when a user comes online the server sends many nearly-identical presence stanzas to remote servers.</p>
<p>The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;. As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' <note><link url='http://archive.jabber.org/docs/proto-draft/envelope.html'>jabber:x:envelope</link> - Message Envelope Information Extension</note> proposal, which this XEP can supersede.</p>
</section1>
<section1 topic='Discovering Server Support' anchor='disco'>
<p>Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &xep0030;. A conforming server MUST respond to disco#info requests.</p>
<section2 topic='Disco to determine support' anchor='disco-support'>
<p>To determine if a server or service supports Extended Stanza Addressing, the requesting entity SHOULD send a disco#info request to it.</p>
@ -210,7 +210,7 @@
relaying across server-to-server connections as a side-effect.</p>
<p>Address headers MAY be included in message or presence
stanzas. They MUST NOT be included as the direct child of an
stanzas. They MUST NOT be included as the direct child of an
IQ stanza.</p>
</section1>
@ -233,7 +233,7 @@
</addresses>
</presence>]]></example>
<p>Each address to which the sender wants the stanza to be re-sent will show up as an &lt;address/&gt; in the &lt;addresses/&gt; element. There are several different types of address, shown below.</p>
<p>An &lt;address/&gt; element MUST possess a 'type' attribute, and MUST possess at least one of the 'jid', 'uri', 'node', and 'desc' attributes. An &lt;address/&gt; element MUST NOT possess both a 'jid' attribute and a 'uri' attribute. If sending through a multicast service, an address MUST include a 'jid' or a 'uri' attribute, unless it is of type 'noreply'.</p>
@ -294,7 +294,7 @@
</address>
<address type='replyroom' jid='jdev@conference.jabber.org'/>
</addresses>
</message>]]></example>
</message>]]></example>
</section2>
</section1>
@ -325,19 +325,19 @@
service also receive the associated unavailable presence.</p>
</section2>
</section1>
<section1 topic='Multicast Usage' anchor='multicast'>
<p>The following usage scenario shows how messages flow through both address-enabled and non-address-enabled portions of the Jabber network.</p>
<p>Note: the logic associated with <em>how</em> to perform the following tasks is purely informational. A conforming service MUST generate output as if these rules had been followed, but need not (and probably <em>will not</em>) use this algorithm.</p>
<ol>
<li>User desires to send a stanza to more than one
recipient.</li>
<li>Client determines the JID of a multicast service,
using Service Discovery.</li>
<li>If no multicast service is found, the client MAY
choose to deliver each stanza individually, or it MAY
query each of the servers associated with desired
@ -346,8 +346,8 @@
<li>If a multicast service is found, the client constructs
a stanza with an address block, and sends it to the
multicast service. (Note: For the following rules, any
address that was marked on the incoming address header
multicast service. (Note: For the following rules, any
address that was marked on the incoming address header
with delivered='true' is never re-delivered.)</li>
<li>The server checks to see if it can deliver to all of
@ -372,12 +372,12 @@
in the original address header, the local server determines
whether the target server supports multicast, using Service
Discovery.</li>
<li>If the target server does not support address headers, the
local server sends a copy of the stanza to each address,
with the 'to' attribute on the outer stanza set to the JID
of the given addressee.</li>
<li>If the target server does support address headers, the server
removes the delivered='true' attributes on each of the
addresses bound for that server, and replaces the 'to'
@ -586,7 +586,7 @@
<ol>
<li>If a noreply address is
specified, a reply SHOULD NOT be generated.</li>
specified, a reply SHOULD NOT be generated.</li>
<li>If one or more replyroom addresses are specified, the client SHOULD
join the specified chat rooms instead of replying directly

4
xep-0034.xml
View File

@ -71,7 +71,7 @@
<section1 topic='Introduction'>
<p>The Simple Authentication and Security Layer (SASL) (see &rfc4422;) provides a generalized method for adding authentication support to connection-based protocols. This document describes a generic XML namespace profile for SASL, that conforms to section 4 of RFC 4422, "Profiling requirements".</p>
<p>This profile may be used for both client-to-server and server-to-server connections. For client connections, the service name used is &quot;jabber-client&quot;. For server connections, the service name used is &quot;jabber-server&quot;. Both these names are registered in the IANA service registry.</p>
<p>The reader is expected to have read and understood the SASL specification before reading this document.</p>
@ -102,7 +102,7 @@
</ol>
<p>After authentication has completed, the client sends a packet to begin the session.</p>
<p>The namespace identifier for this protocol is http://www.iana.org/assignments/sasl-mechanisms.</p>
<p>The following examples show the dialogue between a client [C] and a server [S].</p>

2
xep-0035.xml
View File

@ -122,7 +122,7 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
<p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>XEP-0034</cite> for more information.</p>
<p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1>

2
xep-0036.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Pub-Sub Subscriptions</title>
<abstract>A proposal for the subscribe half of a publish-subscribe protocol within Jabber.</abstract>
<abstract>A proposal for the subscribe half of a publish-subscribe protocol within Jabber.</abstract>
&LEGALNOTICE;
<number>0036</number>
<status>Retracted</status>

80
xep-0037.xml
View File

@ -107,9 +107,9 @@
&lt;iq
id='dsps1'
type='get'
from='rob@nauseum.org/dspsclient'
from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a44'&gt;
&lt;query type='create'
&lt;query type='create'
xmlns='jabber:iq:dsps'
minthroughput='1.5KB'
maxpublic='20'&gt;
@ -146,9 +146,9 @@
<example>
&lt;iq
id='dsps1'
id='dsps1'
type='result'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='create' xmlns='jabber:iq:dsps'
wait='10'
@ -248,7 +248,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
<section3 topic='Connecting to DSPS via SSL method {optional}'>
<p>Client must connect to DSPS on specified port and initiate handshake. This may be attempted after &quot;create&quot; result received or &quot;disconnect&quot; occurred, and prior to &quot;wait&quot; timeout expiring, then send following on stream:</p>
<example>starttls&lt;CR&gt;</example>
<p>Next, regular TLS handshake is initiated. Upon completion, Client must resume DSPS handshake as per section &quot;Connecting to DSPS via default method&quot;. On error connection closed immediately with optional error messages.</p>
@ -335,7 +335,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
<li><strong>&lt;peer/&gt;</strong> body is full JID of the joined peer unless peer of type &quot;relay&quot;, in which case the resource is not reported.</li>
<li><strong>&quot;status&quot;</strong> is new status of peer.</li>
</ul>
<p>Possible failure messages:</p>
@ -346,7 +346,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
</table>
</section3>
</section2>
<section2 topic='Stream administration'>
@ -361,9 +361,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<example>
&lt;iq
id='dsps3'
id='dsps3'
type='set'
from='rob@nauseum.org/dspsclient'
from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='admin' xmlns='jabber:iq:dsps' expire='20' wait='10'&gt;
&lt;comment&gt;welcome to the stream&lt;/comment&gt;
@ -410,18 +410,18 @@ Content-Type: application/octet-stream&lt;CR&gt;
<tr><th>Code</th><th>Message</th><th>Description</th></tr>
<tr><td>403</td><td>Forbidden</td><td><em>(optional)</em> Returned if peer with &quot;slave&quot; rights attempts to use &quot;master&quot; admin privileges.</td></tr>
</table>
<section3 topic='Invitation to stream {optional}'>
<p>Upon invite DSPS will attempt to invite each of the peers like so:</p>
<example>
&lt;iq
id='dsps4'
id='dsps4'
type='get'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='acknowledge'
&lt;query type='acknowledge'
xmlns='jabber:iq:dsps'
status='master'
expire='20'&gt;
@ -447,9 +447,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon drop DSPS will immediately closes the connection to the dropped peer. It then will totally forget this peer right after sending it a notification message like so:</p>
<example>
&lt;iq
&lt;iq
id='dsps5'
type='set'
type='set'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'&gt;
@ -469,9 +469,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<example>
&lt;iq
id='dsps6'
id='dsps6'
type='set'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
&lt;peer status='drop'&gt;JID&lt;/peer&gt;
@ -487,22 +487,22 @@ Content-Type: application/octet-stream&lt;CR&gt;
</ul>
</section3>
</section2>
<section2 topic='Invitation reply'>
<p>An invited peer has the option to accept or reject an invitation to a stream.</p>
<section3 topic='Accepting an invite'>
<p>To accept an invitation to a stream, the peer must reply like so:</p>
<example>
&lt;iq
id='dsps4'
id='dsps4'
type='result'
from='foo@bar.com/moredsps'
from='foo@bar.com/moredsps'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='connect'/&gt;
&lt;/iq&gt;
@ -518,16 +518,16 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon receipt of this reply the DSPS creates a unique resource for this client JID/resource pair. It then prepares the &quot;create&quot; message as described in section &quot;Connection waiting&quot;.</p>
</section3>
<section3 topic='Rejecting an invite'>
<p>Rejecting an invitation can be done in two ways. A peer can forget about the invitation and let the invitation &quot;expire&quot;, or preferably a message can be sent like so:</p>
<example>
&lt;iq
id='dsps4'
id='dsps4'
type='result'
from='foo@bar.com/moredsps'
from='foo@bar.com/moredsps'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'/&gt;
&lt;/iq&gt;
@ -539,10 +539,10 @@ Content-Type: application/octet-stream&lt;CR&gt;
<li><strong>&quot;status&quot;</strong> drop denotes an rejection of invitation.</li>
</ul>
<p>Regardless of the way a rejection was achieved a notification message is sent to the inviting peer, as was described in section &quot;Stream administration&quot;. If unknown &quot;type&quot; is sent, it will be interpreted as a reject. A maximum of one &quot;acknowledge&quot; is allowed during the lifetime of an invitation. If multiple such tags are sent, the first tag takes precedence. Any rejection of a public connection will be ignored.</p>
<p>Regardless of the way a rejection was achieved a notification message is sent to the inviting peer, as was described in section &quot;Stream administration&quot;. If unknown &quot;type&quot; is sent, it will be interpreted as a reject. A maximum of one &quot;acknowledge&quot; is allowed during the lifetime of an invitation. If multiple such tags are sent, the first tag takes precedence. Any rejection of a public connection will be ignored.</p>
</section3>
</section2>
<section2 topic='Disconnection handling'>
@ -554,9 +554,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon such disconnection DSPS notifies all other members of the stream, following the rules stated for the &quot;presence&quot; message, and takes the form of:</p>
<example>
&lt;iq
&lt;iq
id='dsps7'
type='set'
type='set'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
@ -620,9 +620,9 @@ this is the data in ASCII form
<example>
&lt;iq
id='dsps8'
id='dsps8'
type='get'
from='rob@nauseum.org/dspsclient'
from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='who' xmlns='jabber:iq:dsps'/&gt;
&lt;/iq&gt;
@ -638,13 +638,13 @@ this is the data in ASCII form
<p>The query reply is formatted like so:</p>
<example>
&lt;iq
&lt;iq
id='dsps8'
type='result'
type='result'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='who' xmlns='jabber:iq:dsps'&gt;
&lt;peer
&lt;peer
type='master'
id='0'
status='connect'
@ -671,9 +671,9 @@ this is the data in ASCII form
<p>To retrieve listing of all stream configuration/statistics values or public streams, any registered peer sends a message like so:</p>
<example>
&lt;iq
&lt;iq
id='dsps9'
type='get'
type='get'
from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='stats' xmlns='jabber:iq:dsps'/&gt;
@ -689,9 +689,9 @@ this is the data in ASCII form
<example>
&lt;iq
id='dsps9'
id='dsps9'
type='result'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='stats' xmlns='jabber:iq:dsps'
init='00000000000000'
@ -736,12 +736,12 @@ this is the data in ASCII form
<p>All &quot;status&quot; attributes are required. Any other undefined blocks with any multiplicity, are legal in this block as long as their tags are not identical to any tag within the protocol. Results returned do not have any strict order. If &quot;to&quot; in original request contained no resource, multiple &quot;stats&quot; blocks are allowed, where each contains at least one &lt;peer/&gt; block which has &quot;maxpublic&quot; greater than 0. To join a public stream a client must send message as per section &quot;Accepting an invite&quot;.</p>
</section3>
</section2>
<section2 topic='Stream shutdown'>
<p>Stream exists from its &quot;create&quot;ion time to the time when there are no more &quot;master&quot; peers registered with the stream.</p>
<p>Stream exists from its &quot;create&quot;ion time to the time when there are no more &quot;master&quot; peers registered with the stream.</p>
<p>When last &quot;master&quot; peer is dropped from the stream, DSPS will make sure that all the data sent by all the &quot;master&quot; peers was actually copied to all the &quot;slave&quot; peers still present. For every remaining &quot;slave&quot; peer DSPS will initiate a drop event. Once stream is void of any peers it will be totally forgotten by the DSPS and all associated data is released.</p>
@ -749,7 +749,7 @@ this is the data in ASCII form
<section2 topic='Error message format'>
<p>Error messages look like so:</p>
<p>Error messages look like so:</p>
<example>
&lt;iq

32
xep-0040.xml
View File

@ -74,7 +74,7 @@
<p>Multiple levels of sequence numbers are envisaged and will be used in different circumstances. Multiple levels allow a rapid repair of short "transient" breaks whilst catering for longer breaks, recoveries and resynchronisations without placing too great a burden on either subscriber or pubsub component. This discussion explains the use of a dual sequence number environment: link and source.</p>
<p>Sequence numbers will be sent in each publish thus:</p>
<example>
&lt;iq type="set"
&lt;iq type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
@ -96,7 +96,7 @@
<p>The operation of LINK and SOURCE sequence numbers are described below.</p>
</section2>
<section2 topic="Link Level Swquence Numbering">
<p>This will concern itself with data sent on each channel. A
<p>This will concern itself with data sent on each channel. A
channel can be, but is not limited to the following:</p>
<ul>
<li>Socket connection between Subscriber (and/or resource within same) and the Jabber pubsub component.</li>
@ -116,8 +116,8 @@ channel can be, but is not limited to the following:</p>
<section2 topic="Gap Filling">
<p>When a subscriber detects a gap on its link, it can request for the data to be resent thus:</p>
<example>
&lt;iq
type="get"
&lt;iq
type="get"
id="plugthegap1"
from="myclient@server.net"
to="pubsub.localhost"&gt;
@ -130,8 +130,8 @@ channel can be, but is not limited to the following:</p>
<p>Should the pubsub have lost the link context and thus is unable to plug the gaps it will return an error &lt;iq/&gt; packet.</p>
<p>All is not lost. The subscriber has a last-ditch repair scenario by sending last-received source sequence numbers. </p>
<example>
&lt;iq
type="get"
&lt;iq
type="get"
id="plugthegap1"
from="myclient@server.net"
to="pubsub.localhost"&gt;
@ -144,18 +144,18 @@ channel can be, but is not limited to the following:</p>
<p>Due to the non-contiguous nature of source sequence numbers from the subscriber point of view, the values sent must represent not the gap, but the last valid sequence number received. Each source may have a separate sequence number stream. This allows the pubsub component to manage and, if necessary, request gaps itself from the publisher to resynchronise the subscriber. The pubsub or publishing source should have the ability to refuse a rebuild/resynchronise.</p>
<p>It should be possible for the subscriber to send the link and source sequence numbers in the initial request. However, if link information has been discarded by the pubsub component (e.g. the connection was dropped and presence set offline) the link sequence numbers will be reset to zero (re-synchronised) thus:</p>
<example>
&lt;iq
&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
&lt;publish
&lt;publish
ns="data topics"
linkseq="0"
sourceseq="7547392"
from="publisher.fromaplace"&gt;
&lt;/publish&gt;
&lt;publish
&lt;publish
ns="data topics"
linkseq="1"
sourceseq="44211"
@ -168,12 +168,12 @@ channel can be, but is not limited to the following:</p>
<section2 topic="Heartbeats">
<p>During times of low traffic, an active circuit can be provided with regular heartbeat transmissions. Heartbeats will increment the link level sequence numbers. Subscribers missing or detecting overdue heartbeats will thus be able to detect gaps or delays even in low traffic scenarios. If the data is simply delayed, the subscriber stub is in a position to take action (and/or alert the application/user). If data is lost or heartbeats do not arrive in time, the subscriber can decide to request retransmission, disconnect or wait.</p>
<example>
&lt;iq
&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
&lt;publish
&lt;publish
ns="link.heartbeat"
linkseq="57374"
from="pubsub.localhost"&gt;
@ -189,19 +189,19 @@ channel can be, but is not limited to the following:</p>
<p>When a publish packet arrives with a topic or data namespace, there is currently no way of knowing how to interpret the tags therein. Do they replace existing tag values seen? Should previously sent tags that are not in the publish be kept or discarded? Are tag values being updated or was the previous value incorrect?</p>
<p>To resolve this a type field may be added to the &lt;publish/&gt; tag.</p>
<example>
&lt;iq
&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
&lt;publish
&lt;publish
ns="data topics"
linkseq="57372"
sourceseq="7547392"
from="publisher.fromaplace"
type="update"&gt;
&lt;/publish&gt;
&lt;publish
&lt;publish
ns="data topics"
linkseq="57373"
sourceseq="44211"
@ -242,12 +242,12 @@ channel can be, but is not limited to the following:</p>
<p>Tokenised permissioning allows sets of data can be treated en masse. By permitting the concept of "grant" and "deny" permissions simultaneously (settings that define who CAN see something or defining who CANNOT) individual publishers can manage access both broadly and down to very fine granularity.</p>
<p>Permission tokens, if used, should be sent in-band with the data. This will allow data to change its coding online and thus immediately affect permissioning without a redistribution of the permissioning information.</p>
<example>
&lt;iq
&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
&lt;publish
&lt;publish
ns="data topics"
type="update"
permtoken="6747"

122
xep-0042.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Jabber OOB Broadcast Service (JOBS)</title>
<abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
<abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
&LEGALNOTICE;
<number>0042</number>
<status>Retracted</status>
@ -72,7 +72,7 @@
<p>JOBS utilizes a "two-band" authentication mechanism. This allows the end-points to know practically nothing about each other, yet still be assured that the OOB connection is really to/from the Jabber entity its intended to be. The authentication system is then backed-up with explicit authorization requests.</p>
<p>For the OOB portion, clients connect to the host/address and port of the JOBS service for a given session. Once connected, a client-initiated handshake process occurs, and (if successful), then data is routed from the sender's connection to each receiver's connection. The only point at which any error information may be conveyed over the OOB connection is during the handshake process.</p>
<table caption='Terms in Use'>
<tr>
<th>Term</th>
@ -136,12 +136,12 @@
</section2>
<section2 topic='Creating a Session'>
<p>The JOBS protocol supports various scenarios to create sessions. Most of these scenarios allow an entity to determine the possible parameters to create a session with. To actually create a session, the (would-be) sender sends an "iq-set" with a &lt;session action="create"/&gt;. This returns the details of the newly created session, including the ID and OOB host/port.</p>
<p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
<section3 topic='Simple'>
<p>The simplest create request is:</p>
<example caption='Creation request'><![CDATA[
<iq type='set' from='sender@domain/res' to='jobs.domain' id='JOBS1'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -149,27 +149,27 @@
</iq>
]]></example>
<example caption='Creation result'><![CDATA[
<iq
<iq
type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
host='jobs.domain'
host='jobs.domain'
id='01234567'
port='12676'
port='12676'
sender='sender@domain/res'
buffer='0'
expires='30'
expires='30'
receivers='1'/>
</iq>
]]></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>
</section3>
<section3 topic='With Parameters'>
<p>When creating a session, parameters to &lt;session/&gt; can be supplied, explicitly requesting that certain parameters be met (such as buffer size, time to expire, and receiver limit). Since these parameters have lower- and upper-bounds specific to the JOBS service, a sender may need to determine these limits.</p>
<p>To determine the limits, the sender sends an "iq-get" with a &lt;session action="create"/&gt;:</p>
<example caption='Parameter statistics request'><![CDATA[
<iq id='JOBS0' type='get' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'/>
@ -202,7 +202,7 @@
]]></example>
<p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p>
<p>To create a session with specific parameters, the sender sends an "iq-set" as in the "simple" use-case, but then specifying the parameter values desired:</p>
<example caption='Creation request, with parameters'><![CDATA[
<iq id='JOBS1' type='set' to='jobs.domain'>
@ -214,25 +214,25 @@
<iq type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
host='jobs.domain'
host='jobs.domain'
id='01234567'
port='12676'
port='12676'
sender='sender@domain/res'
buffer='0'
expires='-1'
expires='-1'
receivers='1'/>
</iq>
]]></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>Any parameters that exceed the minimums/maximums causes an error.</p>
</section3>
<section3 topic='Form-based'>
<p>In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a &xep0004; form can be embedded in the &lt;session/&gt;.</p>
<p>To create a session using forms, send a &lt;session action="create"/&gt; with an embedded &lt;x xmlns="jabber:x:data"/&gt;:</p>
<example caption='Creation form request'><![CDATA[
<iq type='get' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'>
@ -243,10 +243,10 @@
<example caption='Creation form result'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
host='jobs.domain'
port='12676'
host='jobs.domain'
port='12676'
buffer='0'
expires='-1'
expires='-1'
receivers='1'>
<x xmlns='jabber:x:data' type='form'>
<instructions>Please specify values for the given fields.</instructions>
@ -260,10 +260,10 @@
</session>
</iq>
]]></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>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>
<example caption='Creation request (form-based)'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'>
@ -280,12 +280,12 @@
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
host='jobs.domain'
host='jobs.domain'
id='01234567'
port='12676'
port='12676'
sender='sender@domain/res'
buffer='0'
expires='300'
expires='300'
receivers='1'/>
</iq>
]]></example>
@ -293,7 +293,7 @@
</section2>
<section2 topic='Inviting Receivers'>
<p>Once the session is created, the sender invites receivers to connect. The sender can invite receivers either directly, or via the JOBS service. Most invitations are distributed via &lt;message/&gt;.</p>
<section3 topic='Inviting Directly'>
<p>The sender can invite receivers directly. This is done using a &lt;message/&gt;:</p>
<example caption='Invitation message (direct)'><![CDATA[
@ -309,7 +309,7 @@
receivers='1'/>
</message>
]]></example>
<p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p>
<ul>
<li>host</li>
@ -414,26 +414,26 @@
<section2 topic='Connecting OOB'>
<section3 topic='Initiating and Authenticating'>
<p>When a client connects (sender or receivers), a client-initiated handshake takes place. The purpose of this handshake is to authenticate the OOB connection, in relation to the client's JID. This authentication utilizes both in-band and OOB packets.</p>
<p>To start the handshake, the client sends an "init" packet on its established connection:</p>
<example caption='Client INIT'><![CDATA[
jobs/0.4 init
session-id: 01234567
client-jid: sender@domain/res
]]></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>
<example caption='Server AUTH-CHALLENGE'><![CDATA[
jobs/0.4 auth-challenge
confirm: SID00001234
]]></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>
<example caption='Authentication request (from Client)'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -443,9 +443,9 @@ confirm: SID00001234
</session>
</iq>hehe
]]></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>
<example caption='Authentication result (from Server)'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -456,17 +456,17 @@ confirm: SID00001234
</session>
</iq>
]]></example>
<p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p>
<example caption='Client AUTH-RESPONSE'><![CDATA[
jobs/0.4 auth-response
accept: SID88884321
]]></example>
<p>If the connection is accepted, the JOBS service sends a "connected" packet:</p>
<example caption='Server CONNECTED'><![CDATA[
jobs/0.4 connected
@ -475,9 +475,9 @@ confirm: SID00001234
</section3>
<section3 topic='Authorizing'>
<p>Authenticating ensures the OOB connection matches a particular JID. Authorizing ensures to the service that receiver is allowed to be connected to the session. To determine if the session connection should be accepted or rejected, the JOBS service first checks if the JID matches the sender. This matches against the "full" JID, including node, domain, and resource. If this connection is the sender, it is allowed. Otherwise, the service confirms the connection with the sender.</p>
<p>If a confirmation is required, the service sends an "iq-get" to the sender, with a &lt;session action="authorize"/&gt; containing an &lt;item type"connection" action="confirm"/&gt; with the full JID of the receiver:</p>
<example caption='Confirmation request'><![CDATA[
<iq type='get' to='sender@domain/res' id='JOBS5' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -509,12 +509,12 @@ confirm: SID00001234
</session>
</iq>
]]></example>
<p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p>
</section3>
<section3 topic='Dropping'>
<p>The sender may drop a connection at any time. To drop a connection, the sender sends an "iq-set" with the &lt;session/&gt; containing the "connection" to drop:</p>
<example caption='Drop request'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -524,9 +524,9 @@ confirm: SID00001234
</session>
</iq>
]]></example>
<p>If the connection is successfully dropped, the service returns an "iq-result":</p>
<example caption='Drop result'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -534,20 +534,20 @@ confirm: SID00001234
id='01234567'/>
</iq>
]]></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>
</section3>
</section2>
<section2 topic='Deleting a Session'>
<p>Sessions are deleted either by timeout or explicitly. Sessions are deleted by timeout automatically under certain conditions. Sessions can also be deleted explicity by their senders, at any time. Regardless of the method of deletion, a notice is sent to all connected.</p>
<p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
<section3 topic='Expiring'>
<p>The exact conditions that expire a session are mostly up to the implementation. At a minimum, a session SHOULD be expired when there are less than two connections, and the "expires" time is reached.</p>
</section3>
<section3 topic='Deleting Explicitly'>
<p>To explictly delete a session, the sender sends an "iq-set" containing a &lt;session action="delete"/&gt;:</p>
<example caption='Delete request'><![CDATA[
<iq id='JOBS50' type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -566,7 +566,7 @@ confirm: SID00001234
<section2 topic='Being Notified about Events'>
<section3 topic='Connection Accepted'>
<p>When a connection is accepted, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='accept'/&gt;:</p>
<example caption='"Connection Accepted" message'><![CDATA[
<message to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -577,12 +577,12 @@ confirm: SID00001234
</session>
</message>
]]></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>
</section3>
<section3 topic='Connection Rejected'>
<p>When a connection is rejected, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='reject'/&gt;:</p>
<example caption='"Connection Rejected" message'><![CDATA[
<message to='receiver@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -593,12 +593,12 @@ confirm: SID00001234
</session>
</message>
]]></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>
</section3>
<section3 topic='Connection Dropped'>
<p>When a connection is dropped, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='drop'/&gt;:</p>
<example caption='"Connection Dropped" message'><![CDATA[
<message to='receiver@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -609,12 +609,12 @@ confirm: SID00001234
</session>
</message>
]]></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>
</section3>
<section3 topic='Session Deleted'>
<p>When a session is deleted, any clients connected to the session are immediately disconnected. The "notify" message is sent to the sender and any receivers still connected, with the &lt;session action="notify"/&gt; containing an &lt;item type="status"/&gt;:</p>
<example caption='"Session Deleted (explicitly)" message'><![CDATA[
<message to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@ -636,7 +636,7 @@ confirm: SID00001234
</session>
</message>
]]></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>
</section3>
</section2>
@ -922,7 +922,7 @@ confirm: SID00001234
<td>The JOBS service cannot accept any additional sessions at this time. Future requests may be accepted.</td>
</tr>
</table>
<table caption='&lt;session action="delete"/&gt; errors'>
<tr>
<th>Code</th>

332
xep-0043.xml
View File

@ -40,7 +40,7 @@
<p>Accessing a RDBMS in a generic fashion is a complex and difficult
task. Consequently, this will not be an attempt to XMLize a generic
Database API or query language. Instead, it will providing a
simple mechanism for a JID to read/write data that it has access to
simple mechanism for a JID to read/write data that it has access to
and specifying a model for those schemas to use in xml.</p>
<p>This document has two aims.</p>
<ol>
@ -48,8 +48,8 @@
<li>Perform near SQL-like data manipulation</li>
</ol>
<p>Although designed for use with an RDBMS this document is not
restricted to such uses. It may be used with any data storage
system that can be broken down to a simple table, column/row
restricted to such uses. It may be used with any data storage
system that can be broken down to a simple table, column/row
format. for example comma delimited files.</p>
</section1>
<section1 topic='Prerequisites'>
@ -57,9 +57,9 @@
must be aware of the following.</p>
<section2 topic='Namespace'>
<p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
<p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
will be used until this becomes a jep. Once officially accepted as
a jep and approved as final by the council, it will become
a jep and approved as final by the council, it will become
<link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
</section2>
<section2 topic='Elements'>
@ -132,45 +132,45 @@
&lt;/database&gt;
</code>
<p>All examples will assume the existence of the following rdbms setup. A
<p>All examples will assume the existence of the following rdbms setup. A
database named 'testdb' with tables created with following SQL
script:</p>
<code>
create table tbl_one
(
a_int int,
a_float float,
a_char char(10)
create table tbl_one
(
a_int int,
a_float float,
a_char char(10)
)
create table tbl_two
(
a_date datetime,
a_numeric numeric(9,3)
create table tbl_two
(
a_date datetime,
a_numeric numeric(9,3)
)
</code>
</section2>
</section1>
</section1>
<section1 topic='Usage'>
<section2 topic='Requesting Schemas'>
<example caption='A simple schema request'>
&lt;iq id="001" to="db.host" type="get"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;/iq&gt;
</example>
<p>This is a simple request to discover what tables/procedures
exist on the database testdb. And what permissions are available
to the user. All schema requests will respond within the scope that
exist on the database testdb. And what permissions are available
to the user. All schema requests will respond within the scope that
was asked for. This is to prevent unnecessary data from flooding
the network. So the response for the above request would look
something like:</p>
something like:</p>
<example caption='Response to a schema request'>
&lt;iq id="001" type="result" from="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" permission="both"/&gt;
@ -178,72 +178,72 @@
&lt;/database&gt;
&lt;/iq&gt;
</example>
<p>The response is scoped to only the 'children' of the request.
Since the request was for the testdb database, only the tables
within that database were returned in the result. The reason for
the limitation is to prevent excessively large packets from filling
<p>The response is scoped to only the 'children' of the request.
Since the request was for the testdb database, only the tables
within that database were returned in the result. The reason for
the limitation is to prevent excessively large packets from filling
the network from large schemas.</p>
<p>The response indicates that the user has both read and write
permissions on the table 'tbl_one' and only read permissions on
the table 'tbl_two'. Consequently, the user may only perform get
permissions on the table 'tbl_one' and only read permissions on
the table 'tbl_two'. Consequently, the user may only perform get
requests on 'tbl_two'.</p>
<example caption='Request detailed table schema'>
&lt;iq id="002" type="get" to="db.host"&gt;
&lt;database
&lt;iq id="002" type="get" to="db.host"&gt;
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
&lt;/database&gt;
&lt;/iq&gt;
</example>
<p>The response would look like:</p>
<example caption='Response to detailed request'>
&lt;iq id="002" type="result" from="db.host"&gt;
&lt;database
&lt;iq id="002" type="result" from="db.host"&gt;
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" permission="both"&gt;
&lt;table name="tbl_one" permission="both"&gt;
&lt;col name="a_int" type="int"/&gt;
&lt;col name="a_float" type="float"/&gt;
&lt;col name="a_char" type="char" size="10"/&gt;
&lt;/table&gt;
&lt;/database&gt;
&lt;/iq&gt;
&lt;/iq&gt;
</example>
<p>The schema response for tbl_one is quite intuitive. Three
columns exist, one called a_int of type int (integer), another
a_float of type float and a third called a_char of type char
columns exist, one called a_int of type int (integer), another
a_float of type float and a third called a_char of type char
with a size of ten characters.</p>
</section2>
<section2 topic='Manipulating Data'>
<p>Manipulation of data (select, insert, update, delete) will
definitely not be elegant or easy. SQL allows for some fairly
complex queries on any fully functional RDBMS. Consequently,
the data manipulation will be relatively limited since it is
definitely not be elegant or easy. SQL allows for some fairly
complex queries on any fully functional RDBMS. Consequently,
the data manipulation will be relatively limited since it is
not a goal to translate SQL into xml.</p>
<section3 topic='Selects'>
<p>To indicate a select like query, specify an &lt;iq&gt; of
type get. The table that the query is to be performed against
must be specified. The columns that are to be returned in
the result set must be scoped within the relative table.
Any attribute on the &lt;col&gt; element besides name will be
ignored. e.g. it is not required nor recommended to specify
type get. The table that the query is to be performed against
must be specified. The columns that are to be returned in
the result set must be scoped within the relative table.
Any attribute on the &lt;col&gt; element besides name will be
ignored. e.g. it is not required nor recommended to specify
the data types or the sizes while performing a get.</p>
<example caption='Basic select'>
&lt;iq id="003" type="get" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -258,14 +258,14 @@
select a_int, a_float, a_char
from tbl_one
</example>
<p>It is also possible to specify a limit on the number of rows
returned in the result set by specifying a value for the limit
<p>It is also possible to specify a limit on the number of rows
returned in the result set by specifying a value for the limit
attribute.</p>
<example caption='Basic select with limit'>
&lt;iq id="003" type="get" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" limit="2"&gt;
@ -278,17 +278,17 @@
</example>
<p>In this case a limit of two rows will be returned in the result set.</p>
<p> The result set which is returned will contain all the rows
that met the criteria of the select. There is no schema
information beyond the column names included in the result set.
Each 'row' in the result set is scoped within the corresponding
information beyond the column names included in the result set.
Each 'row' in the result set is scoped within the corresponding
&lt;table&gt; element. This allows for queries on multiple
tables to be used in one &lt;iq&gt; packet.</p>
<example caption='Response to basic select'>
&lt;iq id="003" type="result" from="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -307,13 +307,13 @@
</section3>
<section3 topic='Constraining Result Sets'>
<p>It would be impractical to request the entire contents of the
table every time you needed one row or a subset of the data. You
<p>It would be impractical to request the entire contents of the
table every time you needed one row or a subset of the data. You
can constrain the result set by specifying a where clause.</p>
<example caption='Select with constraints'>
&lt;iq id="004" type="get" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -332,10 +332,10 @@
select a_int, a_float, a_char from tbl_one
where a_int = 1234 and a_float &lt; 200.00
</example>
<p>Attributes only used in the &lt;col&gt; element within a
&lt;where&gt; element are the op (for operator) and conj for
(conjunction). The op is used for comparison operators such
<p>Attributes only used in the &lt;col&gt; element within a
&lt;where&gt; element are the op (for operator) and conj for
(conjunction). The op is used for comparison operators such
as &lt;, &gt;, =, &lt;&gt;, &lt;=, &gt;=</p>
<ul>
@ -354,13 +354,13 @@
<li>not - to negate a result</li>
<li>or - logical OR ||</li>
<li>and - logical AND &amp;&amp;</li>
</ul>
</ul>
<p><strong>Result</strong></p>
<example caption='Response to select with constraints'>
&lt;iq id="003" type="result" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -375,17 +375,17 @@
<section3 topic='Inserts'>
<p>Inserting or altering the stored data in anyway requires
setting the type attribute to a value of set. This indicates
setting the type attribute to a value of set. This indicates
that the user wants to perform a 'insert/update'. The
differentiating factor between an insert and an update operation
differentiating factor between an insert and an update operation
is whether a &lt;where&gt; element is used. If there is no
&lt;where&gt; element then it must be interpreted as an insert.
&lt;where&gt; element then it must be interpreted as an insert.
If a &lt;where&gt; element does exist, then it must be
interpreted as an update.</p>
<example caption='Inserting data'>
&lt;iq id="004" type="set" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -408,14 +408,14 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<p><strong>Result</strong></p>
<p> If there is no result set for the query, as in an update,
insert, delete, then the response must indicate success or
insert, delete, then the response must indicate success or
failure within the &lt;table&gt; element scope. An empty
&lt;table&gt; element indicates success, and a &lt;table&gt;
&lt;table&gt; element indicates success, and a &lt;table&gt;
element containing an &lt;error&gt; element indicates a failure.</p>
<example caption='Response to data insert'>
&lt;iq id="004" type="result" from="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@ -425,10 +425,10 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/database&gt;
&lt;/iq&gt;
</example>
<p> The insert into tbl_one succeeded since the response has an
empty &lt;table&gt; element. However, the insert into tbl_two
failed with a permission denied error. Which is indicated with a
<p> The insert into tbl_one succeeded since the response has an
empty &lt;table&gt; element. However, the insert into tbl_two
failed with a permission denied error. Which is indicated with a
non-empty &lt;table&gt; element.</p>
</section3>
@ -439,7 +439,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Updating'>
&lt;iq id="005" type="set" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -452,7 +452,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/iq&gt;
SQL Syntax:
update tbl_one
update tbl_one
set a_char = 'aaaaaaaaaa'
where a_int = 1234
</example>
@ -464,7 +464,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Response to update'>
&lt;iq id="005" type="result" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@ -476,12 +476,12 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<section3 topic='Deletes'>
<p> If the type attribute has a value of set and there are no
&lt;col&gt; elements scoped within the &lt;table&gt; element,
&lt;col&gt; elements scoped within the &lt;table&gt; element,
then the query must be interpreted as a delete.</p>
<example caption='Simple delete'>
&lt;iq id="006" type="set" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@ -497,13 +497,13 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</example>
<p><strong>Result</strong></p>
<p>Again, if a result set is not generated by a query, then
success or failure must be indicated by the &lt;table&gt; element</p>
<example caption='Response to delete'>
&lt;iq id="006" type="result" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@ -514,35 +514,35 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</section2>
<section2 topic='Procedures'>
<p> Procedures, or stored procedures <note>Apparently procedures
are not as common in RDBMS as I thought. Postgres and MySQL have
functions, but not procedures. So until I, or someone else,
researches this issue this feature is on hold.</note>
, are often handy to make frequently used sql queries execute faster.
These are simply queries stored in a precompiled form and given a
name with a list of parameters. Each RDBMS handles procedures
differently, but the common characteristics are that they are
<p> Procedures, or stored procedures <note>Apparently procedures
are not as common in RDBMS as I thought. Postgres and MySQL have
functions, but not procedures. So until I, or someone else,
researches this issue this feature is on hold.</note>
, are often handy to make frequently used sql queries execute faster.
These are simply queries stored in a precompiled form and given a
name with a list of parameters. Each RDBMS handles procedures
differently, but the common characteristics are that they are
stored server side and have in/out parameters.</p>
<p> The &lt;proc&gt; element will be used to indicate a procedure.
It has similar characteristics to the &lt;table&gt; element. The
core differences are that the &lt;col&gt; elements have permissions
and a &lt;result&gt; element can be used to indicate the value
<p> The &lt;proc&gt; element will be used to indicate a procedure.
It has similar characteristics to the &lt;table&gt; element. The
core differences are that the &lt;col&gt; elements have permissions
and a &lt;result&gt; element can be used to indicate the value
returned by the procedure.</p>
<p> The permission attribute on a &lt;col&gt; element is used to
<p> The permission attribute on a &lt;col&gt; element is used to
indicate whether the parameter is in (read), out (write) or in/out (both). </p>
<p> The only result set acceptable from a procedure is that of the
<p> The only result set acceptable from a procedure is that of the
parameters or &lt;col&gt; element. If the procedure produces a
result set outside of the parameters this should be ignored.</p>
</section2>
<section2 topic='Errors'>
<p> The server must be able to let the client know when an error
<p> The server must be able to let the client know when an error
occurs, instead of just being silent.</p>
<table caption='Error Codes'>
<tr>
<th>Code</th>
@ -558,49 +558,49 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<tr>
<td>398</td>
<td>Invalid Table Name</td>
<td>Returned when the client has requested information from a
<td>Returned when the client has requested information from a
table/procedure which does not exist according to the component.</td>
</tr>
<tr>
<td>397</td>
<td>Invalid Column Name</td>
<td>Returned when the client has requested information from a
<td>Returned when the client has requested information from a
column which does not exist according to the component.</td>
</tr>
<tr>
<td>380</td>
<td>Permission Denied on Table</td>
<td>Returned when the requested action is not allowed for the
<td>Returned when the requested action is not allowed for the
user on the table</td>
</tr>
<tr>
<td>401</td>
<td>Access Denied</td>
<td>Returned when the user does not have permission to use the
<td>Returned when the user does not have permission to use the
component.</td>
</tr>
</table>
<p>If the user requests an action on a table which they do not have
<p>If the user requests an action on a table which they do not have
permission to do the following should be returned</p>
<example caption='Permission denied error'>
&lt;iq id="004" type="error" from="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_two"&gt;
&lt;error code="380"&gt;permission denied on table&lt;/error&gt;
&lt;/table&gt;
&lt;/database&gt;
&lt;/iq&gt;
&lt;/iq&gt;
</example>
<p>If the user is not allowed to access the component the following should be returned</p>
<example caption='General access denied'>
&lt;iq id="004" type="error" from="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;error code="401"&gt;Access Denied&lt;/error&gt;
@ -610,24 +610,24 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</section2>
<section2 topic='Optional Features'>
<p> There are requirements which can be provided by other jabber
components/namespaces, namely the jabber:iq:browse namespace
in-place of Version Negotiation. Due to the inherent limitations
of the above data retrieval mechanisms more sophisticated querying
techniques might be desired. The &lt;query&gt; element will extend
<p> There are requirements which can be provided by other jabber
components/namespaces, namely the jabber:iq:browse namespace
in-place of Version Negotiation. Due to the inherent limitations
of the above data retrieval mechanisms more sophisticated querying
techniques might be desired. The &lt;query&gt; element will extend
the functionality </p>
<section3 topic='Embedded SQL'>
<p> The abilities described in the Basics section are just that,
basic. To provide more flexibility and allow for the full power
of SQL without xmlifying everything, a &lt;sql&gt; element may
<p> The abilities described in the Basics section are just that,
basic. To provide more flexibility and allow for the full power
of SQL without xmlifying everything, a &lt;sql&gt; element may
be implemented to provide this feature.</p>
<p> The &lt;sql&gt; element must be scoped within the &lt;database&gt; element.</p>
<example caption='Embedded sql query'>
&lt;iq id="007" type="get" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;sql&gt; select a_int, a_float from tbl_one &lt;/sql&gt;
@ -639,7 +639,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Response to embedded query'>
&lt;iq id="007" type="result" to="db.host"&gt;
&lt;database
&lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" permission="both"&gt;
@ -658,38 +658,38 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/iq&gt;
</example>
<p> Since SQL is so flexible, the result set schema is not known
until it is returned as a result of the query. Consequently, it
must be sent as the first 'row' of the returned result. Each
<p> Since SQL is so flexible, the result set schema is not known
until it is returned as a result of the query. Consequently, it
must be sent as the first 'row' of the returned result. Each
following row will be the actual data queried for.</p>
<p> If multiple tables are used within one SQL statement, then
then name attribute within the &lt;table&gt; element can not be
accurately denoted with a single table name. The best way to deal
with this situation is to simply use a unique identifier within
the scope of the &lt;database&gt; element. This will allow for
<p> If multiple tables are used within one SQL statement, then
then name attribute within the &lt;table&gt; element can not be
accurately denoted with a single table name. The best way to deal
with this situation is to simply use a unique identifier within
the scope of the &lt;database&gt; element. This will allow for
multiple &lt;sql&gt; results to be scoped within the same result.</p>
</section3>
</section3>
<section3 topic='Version Negotiation'>
<p>It is expected that this protocol will grow and be extended
<p>It is expected that this protocol will grow and be extended
to meet various demands. Therefore, version
negotiation<note>Version Negotiation is being killed since browsing, feature
negotiation, or disco will be able to perform this function,
however it might be useful as an optional feature for clients
that don't implement these yet, especially considering none
of these have been standardized.</note> will be
negotiation<note>Version Negotiation is being killed since browsing, feature
negotiation, or disco will be able to perform this function,
however it might be useful as an optional feature for clients
that don't implement these yet, especially considering none
of these have been standardized.</note> will be
incorporated up front.</p>
<p>When the connection initiator, client end-user or
server/transport, starts a session, it must first send
the version number it expects to use, otherwise, behavior
server/transport, starts a session, it must first send
the version number it expects to use, otherwise, behavior
is undefined.</p>
<code>
&lt;iq id="000" type="get" to="db.host"&gt;
&lt;database
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.1&lt;/version&gt;
&lt;/database&gt;
@ -697,25 +697,25 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</code>
<p>Three responses are possible from the server.</p>
<ol>
<ol>
<li>
<p>It supports that version number and responds with:</p>
<code>
&lt;iq id="000" type="result" from="db.host"&gt;
&lt;database
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.1&lt;/version&gt;
&lt;/database&gt;
&lt;/iq&gt;
</code>
<p>The type of 'result' indicates that the version request was
successful and if the client is satisfied with the version number,
successful and if the client is satisfied with the version number,
may continue with schema requests or whatever.</p></li>
<li><p>It does not support that version number and responds with:</p>
<code>
&lt;iq id="000" type="error" from="db.host"&gt;
&lt;database
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;/iq&gt;
</code>
@ -724,7 +724,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
alternative option.</p>
<code>
&lt;iq id="000" type="error" from="db.host"&gt;
&lt;database
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.2&lt;/version&gt;
&lt;/database&gt;
@ -771,21 +771,21 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;!ELEMENT result (#PCDATA)&gt;
&lt;!ATTLIST error code CDATA #IMPLIED&gt;
&lt;!ATTLIST database name CDATA #IMPLIED&gt;
&lt;!ATTLIST table
name CDATA #IMPLIED
permission (read | write | both) #IMPLIED
&lt;!ATTLIST table
name CDATA #IMPLIED
permission (read | write | both) #IMPLIED
limit CDATA #IMPLIED
&gt;
&lt;!ATTLIST proc name CDATA #IMPLIED&gt;
&lt;!ATTLIST col
name CDATA #IMPLIED
size CDATA #IMPLIED
op (eq | neq | lt | gt | let | get | null) #IMPLIED
conj (not | or | and ) #IMPLIED
permission (read | write | both) #IMPLIED
type (bit | tinyint | integer | utinyint | uinteger |
float | numeric | date | datetime | timestamp |
time | char | vchar | text | blob) #IMPLIED
&lt;!ATTLIST col
name CDATA #IMPLIED
size CDATA #IMPLIED
op (eq | neq | lt | gt | let | get | null) #IMPLIED
conj (not | or | and ) #IMPLIED
permission (read | write | both) #IMPLIED
type (bit | tinyint | integer | utinyint | uinteger |
float | numeric | date | datetime | timestamp |
time | char | vchar | text | blob) #IMPLIED
&gt;
</code>
</section2>

2
xep-0046.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>DTCP</title>
<abstract>Direct TCP connection between two Jabber entities.</abstract>
<abstract>Direct TCP connection between two Jabber entities.</abstract>
&LEGALNOTICE;
<number>0046</number>
<status>Retracted</status>

10
xep-0047.xml
View File

@ -180,7 +180,7 @@
<p>If the responder informs the initiator that it wishes to proceed with the session, the initiator can begin to send data over the bytestream (in addition, because the bytestream is bidirectional, the responder can also send data; see the <link url='#bidi'>Bidirectionality</link> section of this document for details).</p>
<p>Each chunk of data is contained in a &lt;data/&gt; element qualified by the 'http://jabber.org/protocol/ibb' namespace. The data element SHOULD be sent in an IQ stanza to enable proper tracking and throttling, but instead MAY be sent in a message stanza. The data to be sent, prior to base64-encoding and prior to any wrapping in XML, MUST NOT be larger than the 'block-size' determined in the bytestream negotiation.</p>
<example caption='Sending data in an IQ stanza'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='kr91n475'
to='juliet@capulet.com/balcony'
type='set'>
@ -235,11 +235,11 @@
<iq from='juliet@capulet.com/balcony'
id='us71g45j'
to='romeo@montague.net/orchard'
type='result'/>
type='result'/>
]]></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>
<example caption='Recipient does not know about the IBB session'><![CDATA[
<iq type='error'
<iq type='error'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='us71g45j'>
@ -260,7 +260,7 @@
<section1 topic='Use of Message Stanzas' anchor='message'>
<p>It is RECOMMENDED to use IQ stanzas when sending data packets. However, an application MAY use message stanzas instead. If message stanzas are used when sending data packets, the sender SHOULD also use &xep0079; or some other stanza flow-control method. For proper tracking of delivery and processing errors related to data packets, the 'id' attribute SHOULD be used with message stanzas.</p>
<example caption='Sending data in a message stanza'><![CDATA[
<message from='romeo@montague.net/orchard'
<message from='romeo@montague.net/orchard'
id='dsw71gj3'
to='juliet@capulet.com/balcony'>
<data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='i781hf64'>
@ -294,7 +294,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/ibb' in its registry of XML namespaces at &NAMESPACES;.</p>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/ibb' in its registry of XML namespaces at &NAMESPACES;.</p>
</section2>
</section1>

12
xep-0048.xml
View File

@ -114,7 +114,7 @@
<p>Note: The datatypes are as defined in &w3xmlschema2;.</p>
<example caption='An example of the conference element'><![CDATA[
<storage xmlns='storage:bookmarks'>
<conference name='Council of Oberon'
<conference name='Council of Oberon'
autojoin='true'
jid='council@conference.underhill.org'>
<nick>Puck</nick>
@ -168,7 +168,7 @@
<publish node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@ -207,7 +207,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@ -226,7 +226,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@ -255,7 +255,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@ -271,7 +271,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and <cite>XEP-0223</cite>.</p>
<p>Use of the &lt;password/&gt; child of the &lt;conference/&gt; element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage.</p>
<p>Use of the &lt;password/&gt; child of the &lt;conference/&gt; element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

2
xep-0049.xml
View File

@ -112,7 +112,7 @@ SERVER:
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
]]></example>
]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[
CLIENT:

8
xep-0051.xml
View File

@ -74,7 +74,7 @@
<section1 topic='Connection Transfer Protocol' anchor='protocol'>
<p>The transfer packet is addressed to the user from the domain they are logged into, it contains the server address to connect to which can be domain name or ip address, it can also contain an optional port number. There is also the domain specified just in case they have to use a different domain name when they log in or to maintain the original domain.</p>
<example caption='Server tells client to connect to a different server in the cluster (by ip address)'><![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'>
<domain>jabber.org</domain>
<server>123.123.123.122</server>
@ -82,7 +82,7 @@
</iq>
]]></example>
<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'>
<domain>jabber.org</domain>
<server>server2.jabber.org</server>
@ -90,7 +90,7 @@
</iq>
]]></example>
<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'>
<domain>jabber.org</domain>
<server>server3.jabber.org:6222</server>
@ -98,7 +98,7 @@
</iq>
]]></example>
<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'>
<domain>jabber.org</domain>
<server>jabber.org</server>

26
xep-0052.xml
View File

@ -105,7 +105,7 @@
<p>
In order to send a file, the sender must first tell the receiver a little
bit about the file to make sure they will accept it. At the same time they
list the stream methods they support in the order they wish to use them.
list the stream methods they support in the order they wish to use them.
This is done by sending the information in the http://www.jabber.org/protocol/filexfer namespace.
</p>
@ -113,9 +113,9 @@
&lt;iq type='set' id='ft_1' to='recvr@jabber.org/Home'&gt;
&lt;file xmlns='http://www.jabber.org/protocol/filexfer'
action='offer'
id='a0'
name='myfile.txt'
size='1024'
id='a0'
name='myfile.txt'
size='1024'
mime-type='text/plain'&gt;
&lt;feature xmlns='http://jabber.org/protocol/feature-neg'&gt;
&lt;x xmlns='jabber:x:data'&gt;
@ -129,7 +129,7 @@
</example>
<p>
That is the basic request, a more complete requeset with range support is
That is the basic request, a more complete requeset with range support is
shown below.
</p>
@ -137,9 +137,9 @@
&lt;iq type='set' id='ft_1' to='recvr@jabber.org/Home'&gt;
&lt;file xmlns='http://www.jabber.org/protocol/filexfer'
action='offer'
id='a0'
name='myfile.txt'
size='1024'
id='a0'
name='myfile.txt'
size='1024'
mime-type='text/plain'
date='20020412T00:00:00'
hash='23e4ad6b63343b33a333c334'&gt;
@ -158,7 +158,7 @@
&lt;/file&gt;
&lt;/iq&gt;
</example>
<p>If a receiver decides to accept an offered file they request it from the sending with an &lt;iq/&gt; type result. The receiver sends back the id of the file being sent, the method they wish to use, and the range they wish to download (if the sender announced support). When range support is being used the receiver MUST specify the length and MAY specify a beginning offset with the acceptance.</p>
<example caption='Request the Offered File'>
@ -190,7 +190,7 @@
</example>
<p>
If the receiver decides to not accept the file they SHOULD send back an
If the receiver decides to not accept the file they SHOULD send back an
error 403 to the sender.
</p>
@ -253,7 +253,7 @@
<p>
If the transfer does not complete, for any reason after the meta-data
negotiation, the party that has the error SHOULD send an error 500 and
negotiation, the party that has the error SHOULD send an error 500 and
the file id to the other party.
</p>
@ -342,7 +342,7 @@
conditions, error codes and descriptions:</p>
<ul>
<li>
<em>Declining Transfer (403)</em>: During the meta-data negotiation
<em>Declining Transfer (403)</em>: During the meta-data negotiation
the receiver may decline the transfer by sending the 403 error. The
&lt;error/&gt; CDATA MAY contain a descriptive reason why, but is not
necessary.
@ -356,7 +356,7 @@
<em>Transfer Failed (500)</em>: If the file transfer fails for any
reason after negotiation, the error generator SHOULD send a 500 error
to the other party. This is the only error message that both the
sender and reciever may send. The &lt;error/&gt; CDATA MAY contain
sender and reciever may send. The &lt;error/&gt; CDATA MAY contain
information about the failure.
</li>
<li>

200
xep-0054.xml
View File

@ -118,7 +118,7 @@
<EMAIL><INTERNET/><PREF/><USERID>stpeter@jabber.org</USERID></EMAIL>
<JABBERID>stpeter@jabber.org</JABBERID>
<DESC>
More information about me is located on my
More information about me is located on my
personal website: http://www.saint-andre.com/
</DESC>
</vCard>
@ -225,8 +225,8 @@
]]></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>
<example caption="Receiving Another User's vCard"><![CDATA[
<iq from='jer@jabber.org'
to='stpeter@jabber.org/roundabout'
<iq from='jer@jabber.org'
to='stpeter@jabber.org/roundabout'
type='result'
id='v3'>
<vCard xmlns='vcard-temp'>
@ -335,7 +335,7 @@ Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implmentation
on or otherwise explain it or assist in its implmentation
may be prepared, copied, published and distributed, in whole
or in part, without restriction of any kind, provided that
the above copyright notice and this paragraph are included
@ -365,9 +365,9 @@ PARTICULAR PURPOSE.
<!-- ==== -->
<!-- NOTE: the following root element is not used in the
modified vcard-temp DTD published by the Jabber
modified vcard-temp DTD published by the Jabber
project (now XMPP Standards Foundation) and is
included here only for historical purposes;
included here only for historical purposes;
implementations that comply with vcard-temp must
specify the root element as vCard, not xCard. -->
@ -379,35 +379,35 @@ PARTICULAR PURPOSE.
<!ELEMENT vCard (
(VERSION, FN, N),
(NICKNAME?,
PHOTO?,
BDAY?,
ADR?,
LABEL?,
TEL?,
PHOTO?,
BDAY?,
ADR?,
LABEL?,
TEL?,
EMAIL?,
JABBERID?,
MAILER?,
TZ?,
GEO?,
TITLE?,
ROLE?,
LOGO?,
AGENT?,
ORG?,
CATEGORIES?,
NOTE?,
PRODID?,
REV?,
SORT-STRING?,
SOUND?,
UID?,
URL?,
CLASS?,
MAILER?,
TZ?,
GEO?,
TITLE?,
ROLE?,
LOGO?,
AGENT?,
ORG?,
CATEGORIES?,
NOTE?,
PRODID?,
REV?,
SORT-STRING?,
SOUND?,
UID?,
URL?,
CLASS?,
KEY?,
DESC?
)*)>
<!-- vCard specification version property.
<!-- vCard specification version property.
This MUST be 2.0, if the document conforms to RFC 2426. -->
<!ELEMENT VERSION (#PCDATA)>
@ -418,7 +418,7 @@ PARTICULAR PURPOSE.
values must be specified as a comma separated
list of values. -->
<!ELEMENT N ( FAMILY?, GIVEN?, MIDDLE?, PREFIX?, SUFFIX?)>
<!ELEMENT FAMILY (#PCDATA)>
<!ELEMENT GIVEN (#PCDATA)>
<!ELEMENT MIDDLE (#PCDATA)>
@ -441,21 +441,21 @@ PARTICULAR PURPOSE.
multiple values must be specified as a comma separated list
of values. -->
<!ELEMENT ADR (
HOME?,
WORK?,
POSTAL?,
PARCEL?,
(DOM | INTL)?,
PREF?,
POBOX?,
EXTADD?,
STREET?,
LOCALITY?,
REGION?,
PCODE?,
HOME?,
WORK?,
POSTAL?,
PARCEL?,
(DOM | INTL)?,
PREF?,
POBOX?,
EXTADD?,
STREET?,
LOCALITY?,
REGION?,
PCODE?,
CTRY?
)>
<!ELEMENT POBOX (#PCDATA)>
<!ELEMENT EXTADD (#PCDATA)>
<!ELEMENT STREET (#PCDATA)>
@ -466,12 +466,12 @@ PARTICULAR PURPOSE.
<!-- Address label property. -->
<!ELEMENT LABEL (
HOME?,
WORK?,
POSTAL?,
PARCEL?,
(DOM | INTL)?,
PREF?,
HOME?,
WORK?,
POSTAL?,
PARCEL?,
(DOM | INTL)?,
PREF?,
LINE+
)>
@ -480,19 +480,19 @@ PARTICULAR PURPOSE.
<!-- Telephone number property. -->
<!ELEMENT TEL (
HOME?,
WORK?,
VOICE?,
FAX?,
PAGER?,
MSG?,
CELL?,
VIDEO?,
BBS?,
MODEM?,
ISDN?,
PCS?,
PREF?,
HOME?,
WORK?,
VOICE?,
FAX?,
PAGER?,
MSG?,
CELL?,
VIDEO?,
BBS?,
MODEM?,
ISDN?,
PCS?,
PREF?,
NUMBER
)>
@ -501,90 +501,90 @@ PARTICULAR PURPOSE.
<!-- Email address property. Default type is INTERNET. -->
<!ELEMENT EMAIL (
HOME?,
WORK?,
INTERNET?,
PREF?,
X400?,
HOME?,
WORK?,
INTERNET?,
PREF?,
X400?,
USERID
)>
<!ELEMENT USERID (#PCDATA)>
<!-- NOTE: the following element was added by the Jabber
project (now XMPP Standards Foundation) to
handle Jabber IDs; the value must be in the
form of user@host -->
<!ELEMENT JABBERID (#PCDATA)>
<!-- Mailer (e.g., Mail User Agent Type) property. -->
<!ELEMENT MAILER (#PCDATA)>
<!-- Time zone's Standard Time UTC offset. Value must be an
ISO 8601 formatted UTC offset. -->
<!ELEMENT TZ (#PCDATA)>
<!-- Geographical position. Values are the decimal degress of
LATitude and LONgitude. The value should be specified to
LATitude and LONgitude. The value should be specified to
six decimal places.-->
<!ELEMENT GEO (LAT, LON)>
<!-- Latitude value. -->
<!ELEMENT LAT (#PCDATA)>
<!-- Longitude value. -->
<!ELEMENT LON (#PCDATA)>
<!-- Title property. -->
<!ELEMENT TITLE (#PCDATA)>
<!-- Role property. -->
<!ELEMENT ROLE (#PCDATA)>
<!-- Organization logo property. -->
<!ELEMENT LOGO ((TYPE, BINVAL) | EXTVAL)>
<!-- Administrative agent property. -->
<!ELEMENT AGENT (vCard | EXTVAL)>
<!-- Organizational name and units property. -->
<!ELEMENT ORG (ORGNAME, ORGUNIT*)>
<!ELEMENT ORGNAME (#PCDATA)>
<!ELEMENT ORGUNIT (#PCDATA)>
<!-- Application specific categories property. -->
<!ELEMENT CATEGORIES (KEYWORD+)>
<!ELEMENT KEYWORD (#PCDATA)>
<!-- Commentary note property. -->
<!ELEMENT NOTE (#PCDATA)>
<!-- Identifier of product that generated the vCard property. -->
<!ELEMENT PRODID (#PCDATA)>
<!-- Last revised property. The value must be an
<!-- Last revised property. The value must be an
ISO 8601 formatted UTC date/time. -->
<!ELEMENT REV (#PCDATA)>
<!-- Sort string property. -->
<!ELEMENT SORT-STRING (#PCDATA)>
<!-- Formatted name pronunciation property. The value is
either a textual phonetic pronunciation, a BASE64
<!-- Formatted name pronunciation property. The value is
either a textual phonetic pronunciation, a BASE64
encoded binary digital audio pronunciation or a URI to
an external binary digital audio pronunciation.-->
an external binary digital audio pronunciation.-->
<!ELEMENT SOUND (PHONETIC | BINVAL | EXTVAL)>
<!-- Textual phonetic pronunciation. -->
<!ELEMENT PHONETIC (#PCDATA)>
<!-- Unique identifier property. -->
<!ELEMENT UID (#PCDATA)>
<!-- Directory URL property. -->
<!ELEMENT URL (#PCDATA)>
@ -593,19 +593,19 @@ PARTICULAR PURPOSE.
handle free-form descriptive text. -->
<!ELEMENT DESC (#PCDATA)>
<!-- Privacy classification property. -->
<!ELEMENT CLASS (PUBLIC | PRIVATE | CONFIDENTIAL)>
<!ELEMENT PUBLIC EMPTY>
<!ELEMENT PRIVATE EMPTY>
<!ELEMENT CONFIDENTIAL EMPTY>
<!-- Authentication credential or encryption key property. -->
<!ELEMENT KEY (TYPE?, CRED)>
<!ELEMENT CRED (#PCDATA)>
<!-- ==== -->

10
xep-0056.xml
View File

@ -54,7 +54,7 @@ ANSI X.12, EDIFACT/UN and ebXML are all standards. This document describes a fun
<section1 topic='Transmitting ebXML via XMPP'>
<section2 topic='Introduction to ebXML'>
<p>EbXML <note><link url='http://www.ebxml.org'>http://www.ebxml.org</link></note>, a subset of XML that is defined through OASIS.org, is quickly becoming a de-facto standard for electronic, unified, inter and intra business process communication and for business process specification. The direct adjacency to UN/CEFACT EDIFACT, especially object-oriented EDI, make the widespread use of ebXML for automatic business transaction negotiation, process definition, etc. quite likely.
<p>EbXML <note><link url='http://www.ebxml.org'>http://www.ebxml.org</link></note>, a subset of XML that is defined through OASIS.org, is quickly becoming a de-facto standard for electronic, unified, inter and intra business process communication and for business process specification. The direct adjacency to UN/CEFACT EDIFACT, especially object-oriented EDI, make the widespread use of ebXML for automatic business transaction negotiation, process definition, etc. quite likely.
</p>
</section2>
@ -73,12 +73,12 @@ ebXML Messages SHALL be transmitted within Jabber IQ chunks. The value of the 't
]]></example>
<p>
EbXML information is always transmitted in this envelope. No transformation of native ebXML tags into native Jabber tags is performed (e.g., ebXML reception receipt into Jabber reception receipt). The business logic, on top of Jabber transport logic, has to parse incoming IQ chunks and forward received ebXML information to the ebXML Messaging Service. The business logic has as well to pack the ebXML messages into IQ chunks and invoke the message delivery.
EbXML information is always transmitted in this envelope. No transformation of native ebXML tags into native Jabber tags is performed (e.g., ebXML reception receipt into Jabber reception receipt). The business logic, on top of Jabber transport logic, has to parse incoming IQ chunks and forward received ebXML information to the ebXML Messaging Service. The business logic has as well to pack the ebXML messages into IQ chunks and invoke the message delivery.
</p>
<p>
Although a complex business transaction between two or more Trading Partners might require a payload that contains an array of business documents, binary images, or other related Business Information' <note>Walsh. 2002. <em>ebXML: The Technical Specifications</em>; p. 69</note>, only one ebXML message can be (at the moment) transmitted at a time in one message. However, the ebXML Message MAY contain payload in it's own payload envelope.
Although a complex business transaction between two or more Trading Partners might require a payload that contains an array of business documents, binary images, or other related Business Information' <note>Walsh. 2002. <em>ebXML: The Technical Specifications</em>; p. 69</note>, only one ebXML message can be (at the moment) transmitted at a time in one message. However, the ebXML Message MAY contain payload in it's own payload envelope.
</p>
<p>It has to be noted: The karma restriction of XMPP, implied on clients, makes transmission of large amounts of payload (at the moment) to services or other clients from client side nearly impossible. However, components' karma is not restrained.
<p>It has to be noted: The karma restriction of XMPP, implied on clients, makes transmission of large amounts of payload (at the moment) to services or other clients from client side nearly impossible. However, components' karma is not restrained.
</p>
</section2>
@ -166,7 +166,7 @@ EDIFACT/UN is very similar to X.12 and differs only in the meaning of tags and i
</section2>
<section2 topic='Protocol'>
<p>SAP IDocs SHALL be transmitted in a query tag of an IQ chunk. The IQ chunk's type attribute SHALL be 'set. The query's namespace attribute SHALL be set to 'http://jabber.org/protocol/sap_idoc'. The query tag SHALL contain the iDoc, XML aware.
<p>SAP IDocs SHALL be transmitted in a query tag of an IQ chunk. The IQ chunk's type attribute SHALL be 'set. The query's namespace attribute SHALL be set to 'http://jabber.org/protocol/sap_idoc'. The query tag SHALL contain the iDoc, XML aware.
</p>
</section2>

8
xep-0057.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Extended Roster</title>
<abstract>This document defines a way to handle extended roster items.</abstract>
<abstract>This document defines a way to handle extended roster items.</abstract>
&LEGALNOTICE;
<number>0057</number>
<status>Retracted</status>
@ -66,7 +66,7 @@
<section2 topic="Server-side information">
<p>This information is implementation-dependent, so to provide flexibility for it, the <tt>jabber:x:data</tt> namespace defined in &xep0004; must be used. The client can set these parameters by setting this item with this form with <tt>type='submit'</tt>.</p>
<example><![CDATA[<item jid="romeo@montague.net"
name="Romeo"
name="Romeo"
subscription="both">
<x xmlns='jabber:x:data' type='form'>
<field type='list-single' label='Visibility' var='visibility'>
@ -138,7 +138,7 @@
<example><![CDATA[<iq id="roster_1" type="result">
<query xmlns="jabber:iq:roster">
<item jid="romeo@montague.net"
name="Romeo"
name="Romeo"
category="user"
type="client"
subscription="both">
@ -162,7 +162,7 @@
</x>
</item>
<item jid="jdev@conference.jabber.org"
name="Developers Zone"
name="Developers Zone"
category="conference"
type="text"
subscription="none">

2
xep-0058.xml
View File

@ -96,7 +96,7 @@
8.5. Modifying the Member List
8.6. Granting Moderator Privileges
8.7. Revoking Moderator Privileges
8.8. Modifying the Moderator List
8.8. Modifying the Moderator List
...
</text>
</iq>]]></example>

14
xep-0061.xml
View File

@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -37,14 +37,14 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>A very simple namespace contaning display hints for the content in a message. Can be used for
<p>A very simple namespace contaning display hints for the content in a message. Can be used for
person-person collaboration, or by a service managing notes.</p>
</section1>
<section1 topic='Message Extension'>
<p>Normal messages are sent, with a sharednote namespace extending them hinting to any supporting client on
how to display the message as a note instead. Any changes to the note within that client should then be sent
back to the sender, either automatically or when the user saves the note (depending on the update element, by
<p>Normal messages are sent, with a sharednote namespace extending them hinting to any supporting client on
how to display the message as a note instead. Any changes to the note within that client should then be sent
back to the sender, either automatically or when the user saves the note (depending on the update element, by
default on a save action by the user).</p>
<example caption='An Example Shared Note Message'><![CDATA[
@ -66,7 +66,7 @@ default on a save action by the user).</p>
</message>
]]></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>
</section1>
@ -75,7 +75,7 @@ change is sent, only the changed elements are returned.</p>
<p>Each thread is a different shared note. Auto updates should use an internal client timer and batch large
changes into chunks, when the user is typing every 5-10 seconds or so. When the user has made changes that
haven't been sent and an update comes in on the same thread the client should prompt the user with the
haven't been sent and an update comes in on the same thread the client should prompt the user with the
changes offering to replace or save their changes.</p>
</section1>

10
xep-0063.xml
View File

@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -61,7 +61,7 @@
<example caption='Matches all presence packets'><![CDATA[
<presence xmlns='http://jabber.org/protocol/filter/basic'/>
]]></example>
<example caption='Matches all jabber:iq:version IQ packets'><![CDATA[
<iq xmlns='http://jabber.org/protocol/filter/basic'>jabber:iq:version</iq>
]]></example>
@ -69,7 +69,7 @@
<example caption='Matches all packets from user@company.com'><![CDATA[
<from xmlns='http://jabber.org/protocol/filter/basic'>user@company.com</from>
]]></example>
</section1>
<section1 topic='Actions'>
@ -85,11 +85,11 @@
<example caption='Pretend that we don&apos;t exist'><![CDATA[
<bounce xmlns='http://jabber.org/protocol/filter/basic' code='404'/>
]]></example>
<example caption='Send a copy to our home account'><![CDATA[
<copy xmlns='http://jabber.org/protocol/filter/basic'>me@home.com</copy>
]]></example>
</section1>
<section1 topic='Security Considerations'>

6
xep-0064.xml
View File

@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -56,11 +56,11 @@
<example caption='Matches all messages with that have a subject element'><![CDATA[
<xpath xmlns='http://jabber.org/protocol/filter/xpath'>/message/subject</xpath>
]]></example>
<example caption='Matches all presence packets that have an x:delay stamp'><![CDATA[
<xpath xmlns='http://jabber.org/protocol/filter/xpath'>/presence/x[namespace-uri()=='jabber:x:delay']</xpath>
]]></example>
</section1>
<section1 topic='Security Considerations'>

12
xep-0065.xml
View File

@ -308,7 +308,7 @@
to='requester@example.com/foo'
type='error'>
<error type='auth'>
<forbidden
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -320,7 +320,7 @@
to='requester@example.com/foo'
type='error'>
<error type='auth'>
<forbidden
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -332,7 +332,7 @@
to='streamer.example.com'
type='error'>
<error type='cancel'>
<not-allowed
<not-allowed
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -403,7 +403,7 @@ Requester Target
to='requester@example.com/foo'
type='error'>
<error type='modify'>
<not-acceptable
<not-acceptable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -438,7 +438,7 @@ STATUS = X'00'
to='requester@example.com/foo'
type='error'>
<error type='cancel'>
<item-not-found
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -741,7 +741,7 @@ DATA = Target or Requester JID
from='streamer.example.com'
to='target@example.org/bar'
id='zy3v29h6'>
<udpsuccess xmlns='http://jabber.org/protocol/bytestreams'
<udpsuccess xmlns='http://jabber.org/protocol/bytestreams'
dstaddr='Value of Hash'/>
</message>
]]></example>

6
xep-0066.xml
View File

@ -183,11 +183,11 @@
<p>A sample protocol flow is shown below.</p>
<example caption='Stream Initiation Offer'>
<![CDATA[
<iq type='set'
<iq type='set'
from='romeo@montague.net/orchard'
to='juliet@capulet.com/chamber'
id='offer1'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -209,7 +209,7 @@
</example>
<example caption='Stream Initiation Result'>
<![CDATA[
<iq type='result'
<iq type='result'
from='juliet@capulet.com/chamber'>
to='romeo@montague.net/orchard'
id='offer1'>

10
xep-0067.xml
View File

@ -45,7 +45,7 @@
<section1 topic='Introduction'>
<p>
Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
</p>
<p>
So, what this document comes down to: it defines the data architecture for stock data and it specifies, that a 'stocks/' node is recommended to exist, which again holds all symbols as subnodes, which again hold either '/realtime', '/bar' or '/news' as subnodes. The 'bar' subnode contains a 'time descriptor' subnode. The sort of the symbols is defined through the service provider, who can i.e. support Y!ahoo finance symbols, (german) WKNs or official stock symbols.
@ -55,7 +55,7 @@ So, what this document comes down to: it defines the data architecture for stock
<section1 topic="Realtime data distribution">
<p>
Realtime (or close-to-realtime) full stock value data is distributed to a ticker symbol pub/sub location, in the stocks domain. The share data SHALL contain name, time of last trade, most recent stock value, last trade volume, bid, ask, bid size, ask size of the share. If a value is not available, the value MUST be set to '-1'. Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Realtime share value SHALL be published to a position 'realtime' in the ticker symbol domain.
Realtime (or close-to-realtime) full stock value data is distributed to a ticker symbol pub/sub location, in the stocks domain. The share data SHALL contain name, time of last trade, most recent stock value, last trade volume, bid, ask, bid size, ask size of the share. If a value is not available, the value MUST be set to '-1'. Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Realtime share value SHALL be published to a position 'realtime' in the ticker symbol domain.
</p>
<example caption='Component distributes realtime share value ticker data'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='set' id='publish1'>
@ -126,10 +126,10 @@ Realtime (or close-to-realtime) full stock value data is distributed to a ticker
<section1 topic="Distribution of barchart, time framed stock value data ">
<p>Time framed, suitable for barcharts/candle sticks/line diagram, stock value data is distributed to a pub/sub location, the ticker symbol domain in the stocks domain. The share data SHALL contain name, validity time of this data set, open, hi, low, close for this time frame, traded volume in this time span of a share. </p>
<p>If a value is not available, the value MUST be set to '-1'. </p>
<p>Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Time framed, barcharted share data SHALL be published to a position 'bar' in the ticker symbol domain, the subdomain of this position SHALL be the time span information, time span as stated below. It is up to a component, how to to react on subscriptions in various time spans. Implementations are advised to generate data as according to subscribers demands (subscriptions). Values lower than 0:0:0:0:5:0 are not suitable for most implementations.
<p>Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Time framed, barcharted share data SHALL be published to a position 'bar' in the ticker symbol domain, the subdomain of this position SHALL be the time span information, time span as stated below. It is up to a component, how to to react on subscriptions in various time spans. Implementations are advised to generate data as according to subscribers demands (subscriptions). Values lower than 0:0:0:0:5:0 are not suitable for most implementations.
</p>
<p>
The time span SHALL be represented as a string, composed of the amount of years, months, days, hours, minutes, seconds covered by this barchart data set. Time span values SHALL be separated from each other through ':'. A leading zero MAY be attached to digits lower than ten.
The time span SHALL be represented as a string, composed of the amount of years, months, days, hours, minutes, seconds covered by this barchart data set. Time span values SHALL be separated from each other through ':'. A leading zero MAY be attached to digits lower than ten.
</p>
<example caption='Component distributes realtime barcharted share value ticker data'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='set' id='publish1'>
@ -165,7 +165,7 @@ Similar to section 2, timeframed data MAY be transmitted in a message element.
Another important part in a stock system is distribution of stock/share specific news.
</p>
<p>
Stock news are distributed to the pub/sub gateway, to the 'news' location in the ticker symbol subdomain. The stock news are packed in a 'stocknews' chunk. The stocknews chunk contains time, subject, body and source of these news.
Stock news are distributed to the pub/sub gateway, to the 'news' location in the ticker symbol subdomain. The stock news are packed in a 'stocknews' chunk. The stocknews chunk contains time, subject, body and source of these news.
</p>
<example caption='Component publishes share/stock specific news'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='rset' id='publish1'>

28
xep-0068.xml
View File

@ -118,14 +118,14 @@
<p>These are forms that do not have a hidden field of name FORM_TYPE.
Existing processing rules still apply.</p>
<example caption='Message with no FORM_TYPE'><![CDATA[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'>
<thread>vote-thread-reatmon-134</thread>
<x xmlns='jabber:x:data' type='form'>
<title>Vote #134</title>
<instructions>
This is the vote to pick a new mascot.
This is the vote to pick a new mascot.
Thanks for your time!
</instructions>
<field var='mascot' type='list-single'>
@ -156,11 +156,11 @@
<field var="pubsub#node" type="hidden">
<value>generic/pgm-mp3-player</value>
</field>
<field var="pubsub#subscriber_jid" type="jid-single"
<field var="pubsub#subscriber_jid" type="jid-single"
label="Jabber ID of Subscriber">
<value>sub1@foo.com</value>
</field>
<field var="{http://example.com/pubsub}time_restrictions" type="text-multi"
<field var="{http://example.com/pubsub}time_restrictions" type="text-multi"
label="Limit to these time ranges">
<value>09:00-12:00</value>
<value>13:00-17:00</value>
@ -203,7 +203,7 @@
</iq>
]]></example>
<example caption='Service Returns Registration Form'><![CDATA[
<iq
<iq
type='result'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
@ -221,35 +221,35 @@
<field
type='hidden'
var='FORM_TYPE'>
<value>http://jabber.org/protocol/muc#user</value>
<value>http://jabber.org/protocol/muc#user</value>
</field>
<field
<field
type='text-single'
label='First Name'
var='muc#user_first'>
<required/>
</field>
<field
<field
type='text-single'
label='Last Name'
var='muc#user_last'>
<required/>
</field>
<field
<field
type='text-single'
label='Desired Nickname'
var='muc#user_roomnick'>
<required/>
</field>
<field
<field
type='text-single'
label='Your URL'
var='muc#user_url'/>
<field
<field
type='text-single'
label='Email Address'
var='muc#user_email'/>
<field
<field
type='text-multi'
label='FAQ Entry'
var='muc#user_faqentry'/>
@ -258,7 +258,7 @@
</iq>
]]></example>
<example caption='User Submits Registration Form'><![CDATA[
<iq
<iq
type='set'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
@ -266,7 +266,7 @@
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/muc#user</value>
<value>http://jabber.org/protocol/muc#user</value>
</field>
<field var='muc#user_first'>
<value>Brunhilde</value>

44
xep-0070.xml
View File

@ -175,11 +175,11 @@ GET https://files.shakespeare.lit:9345/missive.html HTTP/1.1
<example caption='HTTP Server Returns Authenticate Response'><![CDATA[
401 Unauthorized HTTP/1.1
WWW-Authenticate: Basic realm="xmpp"
WWW-Authenticate: Digest realm="xmpp",
domain="files.shakespeare.lit",
stale=false,
nonce="ec2cc00f21f71acd35ab9be057970609",
qop="auth",
WWW-Authenticate: Digest realm="xmpp",
domain="files.shakespeare.lit",
stale=false,
nonce="ec2cc00f21f71acd35ab9be057970609",
qop="auth",
algorithm="MD5"
]]></example>
</section2>
@ -203,13 +203,13 @@ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
<example caption='HTTP Client Makes Digest Authorization Request'><![CDATA[
Authorization: Digest username="juliet@capulet.com",
realm="xmpp",
nonce="ec2cc00f21f71acd35ab9be057970609",
nonce="ec2cc00f21f71acd35ab9be057970609",
uri="missive.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example>
</section3>
<section3 topic='Additional Authentication Schemes' anchor='http-authz-add'>
@ -226,9 +226,9 @@ Authorization: Digest username="juliet@capulet.com",
<p>If the JID provided was a full JID, the confirmation request SHOULD be sent in an &IQ; stanza of type "get" whose 'to' attribute is set to the full JID, but MAY be sent in a &MESSAGE; stanza.</p>
<p>If the JID provided was a bare JID, the confirmation request MUST be sent in a &MESSAGE; stanza whose 'to' attribute is set to the bare JID; this enables delivery to the "most available" resource for the user (however "most available" is determined by the XMPP Server). The &MESSAGE; stanza SHOULD include a &THREAD; element for tracking purposes and MAY include a &BODY; element that provides human-readable information or instructions. If it however provides a &BODY;, the server SHOULD be able to handle a plaintext reply from the client, in the case where it does not support this XEP.</p>
<example caption='Confirmation Request Sent via IQ'><![CDATA[
<iq type='get'
from='files.shakespeare.lit'
to='juliet@capulet.com/balcony'
<iq type='get'
from='files.shakespeare.lit'
to='juliet@capulet.com/balcony'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
@ -238,7 +238,7 @@ Authorization: Digest username="juliet@capulet.com",
]]></example>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
from='files.shakespeare.lit'
from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>
@ -251,7 +251,7 @@ Authorization: Digest username="juliet@capulet.com",
a7374jnjlalasdf82
If you wish to confirm the request, please reply
to this message by typing "OK". If not, please
to this message by typing "OK". If not, please
reply with "No".
</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
@ -264,16 +264,16 @@ Authorization: Digest username="juliet@capulet.com",
<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>
<example caption='XMPP Client Confirms Request via IQ'><![CDATA[
<iq type='result'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
<iq type='result'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
id='ha000'/>
]]></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>
<example caption='XMPP Client Denies Request via IQ'><![CDATA[
<iq type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
<iq type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
@ -297,7 +297,7 @@ Authorization: Digest username="juliet@capulet.com",
]]></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>
<example caption='XMPP Client Denies Request via Message'><![CDATA[
<message type='error'
<message type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
@ -342,7 +342,7 @@ Content-Length: 3032
<li>The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).</li>
<li>If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with <cite>RFC 6120</cite>.</li>
<li>If a binding of XMPP to HTTP is used (e.g., as specified in <cite>XEP-0124</cite>), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.</li>
</ol>
</ol>
</section2>
<section2 topic='End-to-End Encryption' anchor='security-e2e'>
<p>For added security, the XMPP Server and XMPP Client may wish to communicate using end-to-end encryption. Methods for doing so are outside the scope of this proposal.</p>
@ -365,7 +365,7 @@ Content-Length: 3032
targetNamespace='http://jabber.org/protocol/http-auth'
xmlns='http://jabber.org/protocol/http-auth'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@ -384,7 +384,7 @@ Content-Length: 3032
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>

70
xep-0071.xml
View File

@ -313,7 +313,7 @@
</table>
</section2>
<section2 topic='Hypertext Module Definition' anchor='def-hypertext'>
<p>The Hypertext Module is defined as including the &lt;a/&gt; element only:</p>
<p>The Hypertext Module is defined as including the &lt;a/&gt; element only:</p>
<table caption='Defined Hypertext Module Elements and Attributes'>
<tr><th>Element</th><th>Attributes</th></tr>
<tr><td>&lt;a/&gt;</td><td>class, id, title; style; accesskey, charset, href, hreflang, rel, rev, tabindex, type</td></tr>
@ -372,7 +372,7 @@
<p>For security reasons or because of display constraints, a compliant client MAY choose to display 'alt' text only, not the image itself (for details, see the <link url='#security-code'>Malicious Objects</link> section of this document).</p>
</section2>
<section2 topic='Style Attribute Module Profile' anchor='profile-style'>
<p>This module MUST be supported in XHTML-IM if possible; although clients written for certain platforms (e.g., console clients, mobile phones, and handheld computers) or for certain classes of users (e.g., text-to-speech clients) might not be able to support all of the recommended styles directly, they SHOULD attempt to emulate or translate the defined style properties into text or other presentation styles that are appropriate for the platform or user base in question.</p>
<p>This module MUST be supported in XHTML-IM if possible; although clients written for certain platforms (e.g., console clients, mobile phones, and handheld computers) or for certain classes of users (e.g., text-to-speech clients) might not be able to support all of the recommended styles directly, they SHOULD attempt to emulate or translate the defined style properties into text or other presentation styles that are appropriate for the platform or user base in question.</p>
<p>A full list of recommended style properties is provided below.</p>
<section3 topic='Recommended Style Properties' anchor='profile-style-properties'>
<p><cite>CSS1</cite> defines 42 "atomic" style properties (which are categorized into font, color and background, text, box, and classification properties) as well as 11 "shorthand" properties ("font", "background", "margin", "padding", "border-width", "border-top", "border-right", "border-bottom", "border-left", "border", and "list-style"). Many of these properties are not appropriate for use in text-based instant messaging, for one or more of the following reasons:</p>
@ -765,30 +765,30 @@ That seems fine to me.
The XHTML user agent conformance requirements say to ignore
elements and attributes you don't understand, to wit:
4. If a user agent encounters an element it does
not recognize, it must continue to process the
children of that element. If the content is text,
4. If a user agent encounters an element it does
not recognize, it must continue to process the
children of that element. If the content is text,
the text must be presented to the user.
5. If a user agent encounters an attribute it does
not recognize, it must ignore the entire attribute
5. If a user agent encounters an attribute it does
not recognize, it must ignore the entire attribute
specification (i.e., the attribute and its value).
</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
<p>The <acronym>XHTML</acronym> user agent conformance
requirements say to ignore elements and attributes
<p>The <acronym>XHTML</acronym> user agent conformance
requirements say to ignore elements and attributes
you don't understand, to wit:</p>
<ol type='1' start='4'>
<li><p>
If a user agent encounters an element it does
not recognize, it must continue to process the
If a user agent encounters an element it does
not recognize, it must continue to process the
children of that element. If the content is text,
the text must be presented to the user.
</p></li>
<li><p>
If a user agent encounters an attribute it does
not recognize, it must ignore the entire attribute
If a user agent encounters an attribute it does
not recognize, it must ignore the entire attribute
specification (i.e., the attribute and its value).
</p></li>
</ol>
@ -938,8 +938,8 @@ That seems fine to me.
This schema defines the <html/> element qualified by
the 'http://jabber.org/protocol/xhtml-im' namespace.
The only allowable child is a <body/> element qualified
by the 'http://www.w3.org/1999/xhtml' namespace. Refer
to the XHTML-IM schema driver for the definition of the
by the 'http://www.w3.org/1999/xhtml' namespace. Refer
to the XHTML-IM schema driver for the definition of the
XHTML 1.0 Integration Set.
Full documentation of this Integration Set is contained in
@ -955,8 +955,8 @@ That seems fine to me.
<xs:element name='html'>
<xs:complexType>
<xs:sequence>
<xs:element ref='xhtml:body'
minOccurs='0'
<xs:element ref='xhtml:body'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
@ -994,7 +994,7 @@ That seems fine to me.
- List
- Image
- Style Attribute
The Formal Public Identifier (FPI) for this Integration
Set is:
@ -1011,23 +1011,23 @@ That seems fine to me.
<xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
</xs:annotation>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkphras-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkstruct-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-hypertext-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-image-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlphras-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstruct-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstyle-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-list-1.xsd"/>
<xs:include
<xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/>
</xs:schema>
@ -1044,13 +1044,13 @@ That seems fine to me.
<xs:annotation>
<xs:documentation>
This is the XML Schema module of named XHTML 1.0 content models
for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging
marked-up instant messages between entities that conform to
the Extensible Messaging and Presence Protocol (XMPP). This
Integration Set includes a subset of the modules defined for
XHTML 1.0 but does not redefine any existing modules, nor
does it define any new modules. Specifically, it includes the
This is the XML Schema module of named XHTML 1.0 content models
for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging
marked-up instant messages between entities that conform to
the Extensible Messaging and Presence Protocol (XMPP). This
Integration Set includes a subset of the modules defined for
XHTML 1.0 but does not redefine any existing modules, nor
does it define any new modules. Specifically, it includes the
following modules only:
- Structure
@ -1059,7 +1059,7 @@ That seems fine to me.
- List
- Image
- Style Attribute
Therefore XHTML-IM uses the following content models:
Block.mix; Block-like elements, e.g., paragraphs

82
xep-0072.xml
View File

@ -137,18 +137,18 @@
<p>In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &xep0030; information request to the potential responding entity:</p>
<example caption="Requester queries responder regarding protocol support"><![CDATA[
<iq from='requester@example.com/soap-client'
to='responder@example.com/soap-server'
to='responder@example.com/soap-server'
id='disco1'
type='get'>
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></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>
<example caption="Responder replies regarding protocol support"><![CDATA[
<iq from='responder@example.com/soap-server'
<iq from='responder@example.com/soap-server'
to='requester@example.com/soap-client'
id='disco1'
type='result'>
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='soap'/>
<feature var='http://jabber.org/protocol/soap'/>
@ -169,18 +169,18 @@
<example caption="Requesting entity sends IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap1'
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
@ -208,7 +208,7 @@
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>
</env:Envelope>
</iq>
]]></example>
<p>If the responding entity does not support the SOAP XMPP Binding, it SHOULD return a &unavailable; error:</p>
@ -247,13 +247,13 @@
]]></example>
<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[
<iq from='responder@example.com/soap-server'
<iq from='responder@example.com/soap-server'
id='soap1'
to='requester@example.com/soap-client'
to='requester@example.com/soap-client'
type='result'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -276,7 +276,7 @@
<p:arriving>
<p:airportChoices>JFK LGA EWR</p:airportChoices>
</p:arriving>
</p:return>
</p:return>
</p:itineraryClarification>
</env:Body>
</env:Envelope>
@ -286,12 +286,12 @@
<example caption="Requesting entity sends another IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -367,10 +367,10 @@
<message from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -449,10 +449,10 @@
<message from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -485,17 +485,17 @@
<example caption="IQ-set with SOAP representation header"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
xmlns:rep='http://www.w3.org/2004/08/representation'
to='responder@example.com/soap-server'
type='set'>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
xmlns:rep='http://www.w3.org/2004/08/representation'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<env:Header>
<rep:Representation resource='http://example.org/me.png'>
<rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
</rep:Representation>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -536,8 +536,8 @@
<rep:Representation resource='http://example.org/me.png'>
<rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
</rep:Representation>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@ -592,13 +592,13 @@
</ol>
<p>The following is an example of a WSDL definition for an endpoint that supports the SOAP XMPP binding: a mythical service that translates Shakespearean English into selected modern languages and dialects.</p>
<example caption="Example of WSDL definition for a translation service that supports SOAP over XMPP"><![CDATA[
<definitions
name='ShakespeareTranslation'
<definitions
name='ShakespeareTranslation'
targetNamespace='http://www.example.org/services/BabelFishService.wsdl'>
xmlns='http://schemas.xmlsoap.org/wsdl/'
xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
xmlns:tns='http://shakespeare.lit/translation.wsdl'>
<binding name='ShakespeareTranslationSoap' type='tns:TranslationPortType'>
<soap:binding style='document' transport='http://jabber.org/protocol/soap'/>
<operation name='Translate'>
@ -626,7 +626,7 @@
<section2 topic="Binding Name" anchor='binding-name'>
<p>The SOAP XMPP Binding is identified by the following URI:</p>
<ul>
<li>http://jabber.org/protocol/soap</li>
<li>http://jabber.org/protocol/soap</li>
</ul>
</section2>
<section2 topic="Supported Features" anchor='binding-features'>
@ -1078,7 +1078,7 @@
<td>&lt;VersionMismatch/&gt;</td>
</tr>
</table>
<p>Note: When errors are due to the XMPP transport protocol alone and not to the application layer defined by SOAP, errors MUST be reported with standard XMPP error codes only instead of the XMPP &undefined; condition plus application-specific condition.</p>
<p>Note: When errors are due to the XMPP transport protocol alone and not to the application layer defined by SOAP, errors MUST be reported with standard XMPP error codes only instead of the XMPP &undefined; condition plus application-specific condition.</p>
</section1>
<section1 topic="Business Rules" anchor='bizrules'>
@ -1155,7 +1155,7 @@
</section1>
<section1 topic="Implementation Notes" anchor='impl'>
<p><em>This section is non-normative.</em></p>
<p><em>This section is non-normative.</em></p>
<p>An XMPP entity that supports the SOAP XMPP binding could function as a "SOAP intermediary" that hands a SOAP message off to some other deployment for subsequent processing (HTTP, email, a specialized enterprise messaging platform, etc.) rather than functioning as the "ultimate SOAP receiver" for the message (as these terms are defined in Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). If the intended recipient functions as a SOAP intermediary, implementations should be aware that subsequent processing may alter the representation of SOAP messages.</p>
<p>As an example, consider a component that functions as a gateway between XMPP-based and HTTP-based web services. Its purpose might be to mix HTTP and XMPP for web services and to invoke any web services already accessible through HTTP from XMPP clients.</p>
<p><cite>WS-Routing</cite>, whose aim is to dynamically compose SOAP message paths and processing sequences, can be used in order to reference web services outside of an XMPP network from within it. WS-Routing extends SOAP Envelope Headers with the &lt;path/&gt; element, which specifies the following for the message: the sender's URL (&lt;from/&gt;), the final destination's URL (&lt;to/&gt;), a forward (&lt;forward/&gt;) path with an arbitrary number of intermediaries (&lt;via/&gt;), and an optional return path (&lt;reverse/&gt;). Each intermediary MUST process the &lt;path/&gt; header and update it accordingly to the already performed path; moreover it MAY process the Body of the message.</p>

6
xep-0073.xml
View File

@ -110,7 +110,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note: This protocol suite is obsolete. For updated protocol suites, refer to &xep0211; and &xep0212;.</em></p>
<p>Given the large number of Jabber/XMPP protocols,
<p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of &rfc3920; and &rfc3921;. In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas that are too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
@ -168,9 +168,9 @@
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in <cite>XEP-0078: Non-SASL Authentication</cite> is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see <cite>XEP-0078</cite> regarding the proper order of precedence between SASL authentication and non-SASL authentication).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

16
xep-0074.xml
View File

@ -48,7 +48,7 @@
actor="juliet@capulet.com/church"
oper="uri://capulet.com/inventory#obtain"
target="poison"/>
</iq>
</iq>
]]>
</example>
<p>Here we have the inventory.capulet.com component querying the security component as to whether juliet@ may obtain the requested poison.</p>
@ -63,7 +63,7 @@
target="poison">
<allowed/>
</acl>
</iq>
</iq>
]]>
</example>
<p>Unfortunately, the response is in the affirmative and the romantic tragedy follows.</p>
@ -87,7 +87,7 @@
target="poison">
<allowed/>
</acl>
</iq>
</iq>
]]>
</example>
<example caption='Negative response (denied)'>
@ -101,7 +101,7 @@
target="poison">
<denied/>
</acl>
</iq>
</iq>
]]>
</example>
<example caption='Error response'>
@ -114,7 +114,7 @@
oper="uri://capulet.com/inventory#obtain"
target="poison"/>
<error code="404">No information available</error>
</iq>
</iq>
]]>
</example>
</section1>
@ -126,7 +126,7 @@
from="inventory.capulet.com"
type="get" id="1234">
<query xmlns="http://jabber.org/protocol/sac"/>
</iq>
</iq>
]]>
</example>
<p>The to jid must then respond with a list of operations, if the jid supports SAC.</p>
@ -140,7 +140,7 @@
<oper uri="uri://capulet.com/inventory#add"/>
<oper uri="uri://capulet.com/inventory#remove"/>
</query>
</iq>
</iq>
]]>
</example>
</section1>
@ -151,7 +151,7 @@
<p>To follow.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>As a result of this document, the &REGISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.</p>

18
xep-0075.xml
View File

@ -430,7 +430,7 @@
used to describe the attribute in multiple languages
(differentiated using the 'xml:lang' attribute).</li>
</ul>
<p>The attribute definitions returned to a client should
<p>The attribute definitions returned to a client should
include only attributes the user is authorized to access.</p>
</section3>
<section3 topic='Method Definitions'>
@ -447,7 +447,7 @@
<li>One or more strings of descriptive text, indicating the
use and behavior of this method.</li>
</ul>
<p>The method definitions returned to a client should
<p>The method definitions returned to a client should
include only methods the user is authorized to access.</p>
</section3>
<section3 topic='Class References'>
@ -674,7 +674,7 @@
id='joap_read_1'
from='Station@trainset.example.com/Paddington'
to='Client@example.com'>
<read xmlns='jabber:iq:joap'>
<read xmlns='jabber:iq:joap'>
<attribute>
<name>name</name>
<value>Paddington Station</value>
@ -726,7 +726,7 @@
id='joap_read_2'
from='Train@trainset.example.com/38'
to='Client@example.com'>
<read xmlns='jabber:iq:joap'>
<read xmlns='jabber:iq:joap'>
<attribute>
<name>location</name>
<value>Station@trainset.example.com/Paddington</value>
@ -742,7 +742,7 @@
<value>BoxCar@trainset.example.com/212</value>
<value>Caboose@trainset.example.com/9</value>
</data>
</array>
</array>
</value>
</attribute>
</read>
@ -1620,7 +1620,7 @@
minOccurs='1' maxOccurs='1' />
<element name='desc' type='joap:Description'
minOccurs='0' maxOccurs='unbounded' />
</sequence>
</sequence>
</complexType>
</element>
</sequence>
@ -1799,7 +1799,7 @@
PassengerCar: Car
passengers: i4
Building:
name: string
size: struct (length: i4, width: i4)
@ -1808,12 +1808,12 @@
previous: TrackSegment
next: TrackSegment
Switch:
Switch:
in: TrackSegment
out: TrackSegment[]
boolean switchTo(TrackSegment)
Station: TrackSegment, Building
Station: TrackSegment, Building
]]></example>
</section1>
</xep>

10
xep-0076.xml
View File

@ -43,9 +43,9 @@
</section1>
<section1 topic='Use Cases'>
<section2 topic='Evil Messages'>
<p>If an evil entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p>
<p>If an evil entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p>
<example caption='Evil Entity Sends Evil Message'><![CDATA[
<message
<message
from='iago@shakespeare.lit/pda'
to='emilia@shakespeare.lit/mobile'>
<body>
@ -57,7 +57,7 @@
]]></example>
</section2>
<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>
<example caption='Evil Entity Sends Evil Presence'><![CDATA[
<presence from='iago@shakespeare.lit/pda'>
<show>dnd</show>
@ -67,7 +67,7 @@
]]></example>
</section2>
<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>
<example caption='Evil Entity Sends Evil Message'><![CDATA[
<iq from='iago@shakespeare.lit/pda'
id='evil1'
@ -108,7 +108,7 @@
<p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this document.</p>

4
xep-0077.xml
View File

@ -839,10 +839,10 @@ xmpp:marlowe.shakespeare.lit?unregister
xmlns='jabber:iq:register'
elementFormDefault='qualified'>
<xs:import
<xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>
<xs:import
<xs:import
namespace='jabber:x:oob'
schemaLocation='http://www.xmpp.org/schemas/x-oob.xsd'/>

12
xep-0078.xml
View File

@ -309,11 +309,11 @@
<xs:annotation>
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
protocol has been superseded by SASL Authentication as
defined in RFC 3920 and RFC 6120, and is now obsolete.
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:
http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>
@ -348,11 +348,11 @@
<xs:annotation>
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
protocol has been superseded by SASL Authentication as
defined in RFC 3920 and RFC 6120, and is now obsolete.
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:
http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>

8
xep-0079.xml
View File

@ -1070,7 +1070,7 @@
is "forward" and the message can be forwarded to another XMPP
address, (3) the value is "gateway" and the message can be sent
to a non-XMPP address via a gateway, (4) the value is "none" and
the message cannot be delivered at all, or (5) the value is
the message cannot be delivered at all, or (5) the value is
"stored" and the message can be stored for later delivery.
</processing>
<doc>XEP-0079</doc>
@ -1177,7 +1177,7 @@
targetNamespace='http://jabber.org/protocol/amp'
xmlns='http://jabber.org/protocol/amp'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@ -1196,7 +1196,7 @@
<xs:attribute name='to' use='optional' type='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='invalid-rules'>
<xs:complexType>
<xs:sequence>
@ -1241,7 +1241,7 @@
targetNamespace='http://jabber.org/protocol/amp#errors'
xmlns='http://jabber.org/protocol/amp#errors'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in

16
xep-0080.xml
View File

@ -156,7 +156,7 @@
<li>It shall be possible to encapsulate location in terms of Global Positioning System (GPS) coordinates as well as civil location (city, street, building, etc.).</li>
<li>The GPS encoding mechanism shall have a single set of units, so that receivers do not need to use heuristics to determine an entity's position.</li>
<li>It shall be possible to specify the known amount of error in the GPS coordinates.</li>
<li>It shall be possible to include a natural-language description of the location.</li>
<li>It shall be possible to include a natural-language description of the location.</li>
</ul>
</section1>
<section1 topic='Data Format' anchor='format'>
@ -337,7 +337,7 @@
</iq>
]]></example>
<example caption='Subscriber receives event with payload'><![CDATA[
<message from='portia@merchantofvenice.lit'
<message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
@ -356,7 +356,7 @@
]]></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>
<example caption='User stops publishing geolocation information'><![CDATA[
<iq from='portia@merchantofvenice.lit/pda'
<iq from='portia@merchantofvenice.lit/pda'
id='publish2'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -369,7 +369,7 @@
</iq>
]]></example>
<example caption='Subscriber receives empty event'><![CDATA[
<message from='portia@merchantofvenice.lit'
<message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
@ -436,8 +436,8 @@
<td align='center'>&lt;Street/&gt;
<note>The IMPS specification also enables one to define an intersection (e.g., "Broadway and 34th Street") as the combination of a &lt;Crossing1/&gt; element (e.g., "Broadway") and a &lt;Crossing2/&gt; element (e.g., "34th Street"). To map from IMPS to XMPP, an application SHOULD map such a combination to one XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;A6/&gt;
<note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to XMPP, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one XMPP &lt;street/&gt; element.</note>
<td align='center'>&lt;A6/&gt;
<note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to XMPP, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;STREET/&gt;</td>
</tr>
@ -512,9 +512,9 @@
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/geoloc'
targetNamespace='http://jabber.org/protocol/geoloc'
xmlns='http://jabber.org/protocol/geoloc'
elementFormDefault='qualified'>

18
xep-0081.xml
View File

@ -59,7 +59,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The value of a URI scheme (see &rfc3986;) for Jabber/XMPP communications has long been recognized within the Jabber community, and such a scheme has been formally defined in &rfc5122; as a way of identifying entities that adhere to &xmppcore; or its antecedents. Unfortunately, URI schemes are slow to be accepted on the Internet, such that it might be years (if ever) before widely deployed software such as web browsers will support addresses of the form &lt;xmpp:user@domain&gt;.</p>
<p>Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach
<p>Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach
<note>See, for instance, &lt;<link url='http://www.mozilla.org/docs/web-developer/mimetypes.html'>http://www.mozilla.org/docs/web-developer/mimetypes.html</link>&gt; for information about MIME support in the Mozilla family of web browsers.</note>
is to define a MIME type (in accordance with &rfc2045;) and then reconfigure the relevant server and client software to correctly handle the new MIME type.</p>
<p>Therefore, this document defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.</p>
@ -76,10 +76,10 @@
<ul>
<li>Join a groupchat room.</li>
<li>Register with a service.</li>
<!--
<!--
<li>Send a &xep0030; request.</li>
<li>Search a user directory (see &xep0055;).</li>
<li>Request another user's vCard.</li>
<li>Request another user's vCard.</li>
-->
</ul>
<p>These use cases are defined below.</p>
@ -203,19 +203,19 @@ Optional parameters: (charset) Same as charset parameter of
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023; per Section 11.5
of RFC 3920, the encoding must be UTF-8.
Security considerations: All of the security considerations
specified in RFC 3023 and RFC 3920 apply to this XML media
Security considerations: All of the security considerations
specified in RFC 3023 and RFC 3920 apply to this XML media
type. Refer to Section 11 of XSF XEP-0081.
Interoperability considerations: (none)
Specification: XSF XEP-0081
Applications which use this media type: non-XMPP applications
(e.g., web browsers or email clients) that wish to invoke
XMPP-compliant applications for instant messaging and
XMPP-compliant applications for instant messaging and
presence functionality.
Additional information: This media type is not to be confused
with the "application/xmpp+xml" media type, which is for
Additional information: This media type is not to be confused
with the "application/xmpp+xml" media type, which is for
use by native XMPP applications.
Person and email address to contact for further information:
Person and email address to contact for further information:
XMPP Registrar, <registrar@xmpp.org>
Intended usage: COMMON
Author/Change controller: XSF, XMPP Registrar

6
xep-0084.xml
View File

@ -263,9 +263,9 @@
]]></example>
<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[
<iq type='result'
from='juliet@capulet.lit'
to='romeo@montague.lit/home'
<iq type='result'
from='juliet@capulet.lit'
to='romeo@montague.lit/home'
id='retrieve1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:avatar:data'>

46
xep-0085.xml
View File

@ -314,7 +314,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<section1 topic='A Simple Example' anchor='example-basic'>
<p>In the following conversation, both User &lt;bernardo@shakespeare.lit&gt; and Contact &lt;francisco@shakespeare.lit&gt; support chat state notifications.</p>
<example caption="User Sends Initial Content Message With &lt;active/&gt; Notification"><![CDATA[
<message
<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit'
type='chat'>
@ -323,7 +323,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</message>
]]></example>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message
<message
from='francisco@shakespeare.lit/elsinore'
to='bernardo@shakespeare.lit/pda'
type='chat'>
@ -333,7 +333,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit/elsinore'
type='chat'>
@ -341,7 +341,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</message>
]]></example>
<example caption="User Sends a Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message
<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit/elsinore'
type='chat'>
@ -352,9 +352,9 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<p>And so forth.</p>
</section1>
<section1 topic='A Detailed Conversation' anchor='example-detail'>
<p>The following conversation flow illustrates in more detail the workings of chat state notifications (in this case also using threads) between a User &lt;romeo@shakespeare.lit&gt; and a Contact &lt;juliet@capulet.com&gt;.</p>
<p>The following conversation flow illustrates in more detail the workings of chat state notifications (in this case also using threads) between a User &lt;romeo@shakespeare.lit&gt; and a Contact &lt;juliet@capulet.com&gt;.</p>
<example caption="User Sends Initial Content Message"><![CDATA[
<message
<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com'
type='chat'>
@ -369,7 +369,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></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>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -383,7 +383,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -393,8 +393,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
from='romeo@montague.net/orchard'
<message
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@ -403,8 +403,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></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>
<example caption="User's Client Sends Standalone &lt;paused/&gt; Notification"><![CDATA[
<message
from='romeo@montague.net/orchard'
<message
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@ -413,8 +413,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
from='romeo@montague.net/orchard'
<message
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@ -423,8 +423,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo finally sends his reply.</p>
<example caption="User Replies"><![CDATA[
<message
from='romeo@montague.net/orchard'
<message
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@ -434,7 +434,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -449,7 +449,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -459,7 +459,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -469,7 +469,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>The conversation continues, but Juliet is called away again by that nagging Nurse:</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -482,7 +482,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<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[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@ -492,7 +492,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></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>
<example caption="User's Client Sends Content Message with New Thread ID"><![CDATA[
<message
<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
@ -507,7 +507,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></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>
<example caption="Contact's Client Sends Content Message"><![CDATA[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>

2
xep-0086.xml
View File

@ -83,7 +83,7 @@
<section1 topic='Supporting Legacy Entities'>
<p>XMPP-compliant entities can issue errors to legacy clients and servers by adding a &quot;code&quot; attribute to the &lt;error/&gt; element it sends.</p>
<example caption='A simple error response'><![CDATA[
<message
<message
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'
type='error'>

42
xep-0087.xml
View File

@ -84,7 +84,7 @@
Receiver rejects the stream initiation, EUC
</li>
</ol>
</section2>
</section1>
<section1 topic='Basic Usage'>
@ -95,9 +95,9 @@
</p>
<example caption='Requesting Disco Information From Receiver'>
<![CDATA[
<iq
type='get'
to='receiver@jabber.org/resource'
<iq
type='get'
to='receiver@jabber.org/resource'
from='sender@jabber.org/resource'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -132,8 +132,8 @@
<example caption='Offer Stream Initiation'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'
profile='http://jabber.org/protocol/si/profile/profile-name'>
@ -155,8 +155,8 @@
<example caption='Offer Stream Initiation (Profile in NS)'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'>
<profile xmlns='http://jabber.org/protocol/si/profile/profile-name'>
@ -181,8 +181,8 @@
<!--
<example caption='Offer Regular File Transfer (Alternate Stream Negotiation)'>
<![CDATA[
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'
profile='filexfer'>
@ -249,8 +249,8 @@
</example>
<example caption='Offer to Start a MP3 Stream'>
<![CDATA[
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='s0'
mime-type='audio/x-mp3'
profile='streaming-audio'>
@ -267,8 +267,8 @@
</example>
<example caption='Offer to Start a MP3 Stream (Alternate Stream Negotiation)'>
<![CDATA[
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='s0'
mime-type='audio/x-mp3'
profile='streaming-audio'>
@ -288,7 +288,7 @@
accept the stream. This information is transported in Stream Initiation
through a <em>profile</em>. A profile is a series of required and
optional headers that describe the stream data or how the stream is to be
used. Each Stream Initiation MUST have only one profile, so the stream
used. Each Stream Initiation MUST have only one profile, so the stream
usage is kept clear.
</p>
<p>
@ -304,8 +304,8 @@
decided upon. Each piece of information will be transported in a
&lt;header&gt; tag. The name attribute is a descriptive key that can be
looked up at the XMPP Registrar or XEP describing the profile. The
actual data in the &lt;header&gt; is the fact related to the name
attribute. It must also be stated whether the header is required or
actual data in the &lt;header&gt; is the fact related to the name
attribute. It must also be stated whether the header is required or
optional.
</p>
<p>
@ -385,7 +385,7 @@
meanings and data:</p>
<ul>
<li>
<em>Declining Transfer (403)</em>: During the Stream Initiation
<em>Declining Transfer (403)</em>: During the Stream Initiation
the Receiver may decline the transfer by sending the 403 error. The
&lt;error/&gt; CDATA MAY contain a descriptive reason why, but is not
necessary.
@ -406,14 +406,14 @@
</section1>
<section1 topic='IANA Considerations'>
<p>
This document uses the MIME types as recorded by IANA, but no other direct
This document uses the MIME types as recorded by IANA, but no other direct
interaction is necessary.
</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>
The "http://jabber.org/protocol/si" namespace will be registered.
The registrar will track header profiles for different stream initiation
The "http://jabber.org/protocol/si" namespace will be registered.
The registrar will track header profiles for different stream initiation
uses.
</p>
</section1>

6
xep-0088.xml
View File

@ -68,7 +68,7 @@
<section2 topic='Service Discovery'>
<p>&xep0030; SHALL be used for discovering support for webtabs on servers.</p>
<example caption='Disco info response containing support for webtabs'><![CDATA[
<iq
<iq
type='result'
from='domain.com'
to='user@domain/resource'
@ -79,7 +79,7 @@
</iq>]]></example>
<p>It is RECOMMENDED that the jabber server itself (JSM in jabberd) serves the webtab list, but if desired by the server implementor they MAY be served by a separate host/component.</p>
<example caption='Separate webtab host specified by server'><![CDATA[
<iq
<iq
type='result'
from='domain.com'
to='user@domain/resource'
@ -91,7 +91,7 @@
</query>
</iq>
<iq
<iq
type='result'
from='webtabs.domain.com'
to='user@domain/resource'

2
xep-0090.xml
View File

@ -110,7 +110,7 @@
The protocol documented by this schema is defined in
XEP-0090: http://www.xmpp.org/extensions/xep-0090.html
NOTE: This protocol has been deprecated in favor of the
NOTE: This protocol has been deprecated in favor of the
Entity Time protocol specified in XEP-0202:
http://www.xmpp.org/extensions/xep-0202.html
</xs:documentation>

2
xep-0091.xml
View File

@ -153,7 +153,7 @@
The protocol documented by this schema is defined in
XEP-0091: http://www.xmpp.org/extensions/xep-0091.html
NOTE: This protocol has been deprecated in favor of the
NOTE: This protocol has been deprecated in favor of the
Delayed Delivery protocol specified in XEP-0203:
http://www.xmpp.org/extensions/xep-0203.html
</xs:documentation>

2
xep-0093.xml
View File

@ -69,7 +69,7 @@
<message to='hamlet@denmark' from='horatio@denmark'>
<subject>Visitors</subject>
<body>This message contains roster items.</body>
<x xmlns='jabber:x:roster'>
<x xmlns='jabber:x:roster'>
<item jid='rosencrantz@denmark'
name='Rosencrantz'>
<group>Visitors</group>

12
xep-0095.xml
View File

@ -107,8 +107,8 @@
<section2 topic='Discovery' anchor='usecase-disco'>
<p>Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they wish to use. This is typically accomplished using &xep0030;:</p>
<example caption='Requesting Disco Information From Receiver'><![CDATA[
<iq type='get'
to='receiver@jabber.org/resource'
<iq type='get'
to='receiver@jabber.org/resource'
from='sender@jabber.org/resource'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -298,7 +298,7 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>
This document uses the MIME types as recorded by the IANA, but no direct
This document uses the MIME types as recorded by the IANA, but no direct
interaction with the IANA is necessary.
</p>
</section1>
@ -331,8 +331,8 @@
targetNamespace='http://jabber.org/protocol/si'
xmlns='http://jabber.org/protocol/si'
elementFormDefault='qualified'>
<xs:import
<xs:import
namespace='http://jabber.org/protocol/feature-neg'
schemaLocation='http://www.xmpp.org/schemas/feature-neg.xsd'/>
@ -360,7 +360,7 @@
<xs:attribute name='profile' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='bad-profile' type='empty'/>
<xs:element name='no-valid-streams' type='empty'/>

22
xep-0096.xml
View File

@ -126,7 +126,7 @@
with the possibility of one child describing the optional ranged transfers.
</p>
<p>
The root element is &lt;file&gt; and has four attributes. The attributes
The root element is &lt;file&gt; and has four attributes. The attributes
are used only during the offer stage of stream initiation:</p>
<ul>
<li><em>size</em> - The size, in bytes, of the data to be sent.</li>
@ -143,14 +143,14 @@
&lt;range&gt;. Both are OPTIONAL.
</p>
<p>
&lt;desc&gt; is used to provide a sender-generated description of the file so
the receiver can better understand what is being sent. It MUST NOT be sent in
&lt;desc&gt; is used to provide a sender-generated description of the file so
the receiver can better understand what is being sent. It MUST NOT be sent in
the result.
</p>
<p>
When &lt;range&gt; is sent in the offer, it should have no
When &lt;range&gt; is sent in the offer, it should have no
attributes. This signifies that the
sender can do ranged transfers. When a Stream Initiation result is sent
sender can do ranged transfers. When a Stream Initiation result is sent
with the &lt;range&gt; element, it uses these attributes:</p>
<ul>
<li>
@ -165,10 +165,10 @@
</li>
</ul>
<p>Both attributes are OPTIONAL on the &lt;range&gt; element. Sending no
attributes is synonymous with not sending the &lt;range&gt;
attributes is synonymous with not sending the &lt;range&gt;
element. When no &lt;range&gt; element is sent in the
Stream Initiation result, the Sender MUST send the complete file starting at
offset 0. More generally, data is sent over the stream byte for byte starting
offset 0. More generally, data is sent over the stream byte for byte starting
at the offset position for the length specified.
</p>
<section2 topic='Mandatory-to-Implement Technologies' anchor='protocol-tech'>
@ -180,7 +180,7 @@
<example caption='Simple Profile Usage in Stream Initiation Offer'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -217,7 +217,7 @@
<example caption='Complete Profile Usage in Stream Initiation Offer'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -399,7 +399,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
targetNamespace='http://jabber.org/protocol/si/profile/file-transfer'
xmlns='http://jabber.org/protocol/si/profile/file-transfer'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@ -419,7 +419,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
<xs:attribute name='size' type='xs:integer' use='required'/>
</xs:complexType>
</xs:element>
<xs:element name='range'>
<xs:complexType>
<xs:simpleContent>

4
xep-0097.xml
View File

@ -66,8 +66,8 @@
<example><![CDATA[
<message to="jdev@jabber.org" from="calendar.jabber.org" type="normal">
<body>
Protocol gathering every Tuesday at 22:00 UTC
located in foundation@conference.jabber.org
Protocol gathering every Tuesday at 22:00 UTC
located in foundation@conference.jabber.org
</body>
<ical xmlns="http://jabber.org/protocol/gw/ical">
BEGIN:VCALENDAR

88
xep-0098.xml
View File

@ -31,7 +31,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The 'jabber:iq:private' namespace has been
<p>The 'jabber:iq:private' namespace has been
documented in &xep0049; according to the historical behavior
of current implementations. However there are two backward compatible
improvements to the protocol introduced in this standard
@ -46,33 +46,33 @@ with this standard.</p>
</section1>
<section1 topic='private-xml Namespace'>
<section2 topic='Description'>
<p>A Jabber client can store any arbitrary XML on the server side by sending an
&IQ; chunk of type "set" to the server with a &QUERY; child scoped by the
'http://jabber.org/protocol/private-xml' namespace. The &QUERY; element MUST contain a single, arbitrary
XML fragment. That fragment MUST be scoped by its
<p>A Jabber client can store any arbitrary XML on the server side by sending an
&IQ; chunk of type "set" to the server with a &QUERY; child scoped by the
'http://jabber.org/protocol/private-xml' namespace. The &QUERY; element MUST contain a single, arbitrary
XML fragment. That fragment MUST be scoped by its
own namespace. Any existing data stored on the server with the same fully qualified
element name (tag name + namespace) is replaced by the new data.</p>
<p>The data can then be retrieved by sending an &IQ;
of type "get" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace,
which in turn MUST contain a single child element scoped by the namespace used
<p>The data can then be retrieved by sending an &IQ;
of type "get" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace,
which in turn MUST contain a single child element scoped by the namespace used
for storage of that fragment. The fully qualified element name is used to locate
matching XML data on the server. If no matching data is found, the server will
respond with the empty query child element and not an error.</p>
<p>Finally, existing data on the server can be removed by sending an &IQ;
of type "set" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace and
containing an 'action' attribute with value 'delete',
which in turn MUST contain a single child element scoped by the namespace used
<p>Finally, existing data on the server can be removed by sending an &IQ;
of type "set" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace and
containing an 'action' attribute with value 'delete',
which in turn MUST contain a single child element scoped by the namespace used
for storage of that fragment. The fully qualified element name is used to locate
matching XML data on the server. The server responds with a successful result
whether a matching data fragment was found or not (it's successful because the
provided data no longer exits on the server). Deleting data using this method is
indistinguishable from setting an empty XML fragment as far as the behavior this
protoco is concerned. However, deleting data MUST remove the data from the server
which may be implemented differently than the case of setting the data to an empty
indistinguishable from setting an empty XML fragment as far as the behavior this
protoco is concerned. However, deleting data MUST remove the data from the server
which may be implemented differently than the case of setting the data to an empty
element. This may have significance in the context of future advanced XML storage protocols.
Using the basic private XML data storage protocol, Jabber entities can create, read, update, and delete
private data on the server. The data stored might be
anything, as long as it is valid XML. One typical usage for this namespace is the
private data on the server. The data stored might be
anything, as long as it is valid XML. One typical usage for this namespace is the
server-side storage of client preferences.</p>
</section2>
<section2 topic='Methods'>
@ -85,10 +85,10 @@ server-side storage of client preferences.</p>
</table>
</section2>
<section2 topic='Elements'>
<p>The root element of this namespace is query. A single child
element with a proper namespace must be included otherwise the server will
respond with error code 406. Only one element can be queried or set in a
single IQ request. However, multiple elements, each containing data,
<p>The root element of this namespace is query. A single child
element with a proper namespace must be included otherwise the server will
respond with error code 406. Only one element can be queried or set in a
single IQ request. However, multiple elements, each containing data,
can be stored independently on the server using separate set queries.</p>
<example caption='Client Stores Private Data'><![CDATA[
@ -102,12 +102,12 @@ CLIENT:
</iq>
SERVER:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
]]></example>
]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[
CLIENT:
@ -118,10 +118,10 @@ CLIENT:
</iq>
SERVER:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1002">
<query xmlns="http://jabber.org/protocol/private-xml">
<exodus xmlns="exodus:prefs">
@ -143,10 +143,10 @@ CLIENT:
</iq>
SERVER:
<iq
type="error"
from="hamlet@shakespeare.lit"
to="macbeth@shakespeare.lit"
<iq
type="error"
from="hamlet@shakespeare.lit"
to="macbeth@shakespeare.lit"
iq="1003">
<query xmlns="http://jabber.org/protocol/private-xml">
<exodus xmlns="exodus:prefs">
@ -204,16 +204,16 @@ CLIENT:
</iq>
SERVER (does not have data in "imaginary" namespace, returns empty element):
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1006">
<query xmlns="http://jabber.org/protocol/private-xml">
<data xmlns="imaginary"/>
</query>
</iq>
]]></example>
]]></example>
<p>Finally, the client can delete data from the server using the delete query action.</p>
<example caption='User Deletes Data'><![CDATA[
CLIENT:
@ -224,12 +224,12 @@ CLIENT:
</iq>
SERVER (server responds with success):
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1006"/>
]]></example>
]]></example>
</section2>

122
xep-0099.xml
View File

@ -32,7 +32,7 @@
</header>
<section1 topic='Introduction'>
<p>There is a need for consistent query behavior amongst XMPP &IQ; protocols. Currently
each protocol invents it's own, slightly different behavior for conducting
each protocol invents it's own, slightly different behavior for conducting
query behavior to create, read, update, and delete (CRUD) recipient node data. This document defines a generic
query acton protocol to standardize behavior across &IQ; protocols. In addition, we hope
this standard will make other protocols easier to understand and implement by using a common
@ -50,14 +50,14 @@ all request-response interactions. The particular action to be taken MUST be set
in the &IQ; &QUERY; sub-element. The action attribute MUST have a value of 'create', 'read',
'update', or 'delete'. Responses use the standard &IQ; 'result' and 'error' types.
For backward compatibility, an &IQ; 'get' query is treated as equivalent to an &IQ; 'set'
query with action of 'read'. Action protocols may require all or just a subset of these
query with action of 'read'. Action protocols may require all or just a subset of these
actions depending on the desired outcome.</p>
<p>In addition to the action attribute an optional "strict" attribute may be set in the &IQ; &QUERY;
sub-element. The only valid values for strict is "true" or "false" (case sensitive).
The strict behavior of actions causes more errors to be returned which tends to make
protocols more robust but also more complex. Action protocols MUST define the default value of
the "strict" attribute in the context of that protocol. In addition, some protocols may
not wish to allow changing the strict default, so action protocols MUST declare
the "strict" attribute in the context of that protocol. In addition, some protocols may
not wish to allow changing the strict default, so action protocols MUST declare
whether the strict behavior of the protocol may be set in the &IQ; &QUERY; sub-element.</p>
</section2>
<section2 topic='Actions'>
@ -119,13 +119,13 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
]]></example>
<p>With strict actions enabled, conflict data will cause the create action
]]></example>
<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>
<example caption='Client Stores New Private Data but Conflicts'><![CDATA[
SENDER:
@ -138,10 +138,10 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="409">Conflict</error>
<exodus xmlns="exodus:prefs">
@ -149,7 +149,7 @@ RECIPIENT:
</exodus>
</query>
</iq>
]]></example>
]]></example>
</section2>
</section1>
@ -183,10 +183,10 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001">
<query xmlns="jabber:iq:private" action="read" strict="true">
<exodus xmlns="exodus:prefs"/>
@ -194,8 +194,8 @@ RECIPIENT:
</exodus>
</query>
</iq>
]]></example>
<p>With strict actions enabled, the absence of matching data will cause the read action
]]></example>
<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>
<example caption='Client Reads Private Data but Not Found (strict)'><![CDATA[
SENDER:
@ -206,18 +206,18 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<data xmlns="imaginary"/>
</query>
</iq>
]]></example>
<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
]]></example>
<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
on the server.</p>
<example caption='Client Reads Private Data but Not Found (not strict)'><![CDATA[
SENDER:
@ -228,15 +228,15 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1003">
<data xmlns="imaginary"/>
</query>
</iq>
]]></example>
]]></example>
</section2>
</section1>
@ -270,13 +270,13 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
]]></example>
<p>With strict actions enabled, the absence of existing data will cause the update action
]]></example>
<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>
<example caption='Client Updates Private Data but None Found'><![CDATA[
SENDER:
@ -289,10 +289,10 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<exodus xmlns="exodus:prefs">
@ -300,7 +300,7 @@ RECIPIENT:
</exodus>
</query>
</iq>
]]></example>
]]></example>
</section2>
</section1>
@ -332,13 +332,13 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
]]></example>
<p>With strict actions enabled, the absence of existing data will cause the delete action
]]></example>
<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>
<example caption='Client Deletes Private Data but None Found (strict)'><![CDATA[
SENDER:
@ -349,17 +349,17 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="error"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<data xmlns="imaginary"/>
</query>
</iq>
]]></example>
<p>With strict actions disabled, the absence of existing data will not cause the delete action
]]></example>
<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>
<example caption='Client Deletes Private Data but None Found (not strict)'><![CDATA[
SENDER:
@ -370,12 +370,12 @@ SENDER:
</iq>
RECIPIENT:
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
<iq
type="result"
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1003"/>
]]></example>
]]></example>
</section2>
</section1>
<section1 topic='Defining an Action Protocol'>

228
xep-0102.xml
View File

@ -91,18 +91,18 @@
<section3 topic="End To End Protection">
<p>It is easy to imagine XMPP systems in which the servers play active, fundamental roles in the protection of conversation data. Such systems could offer many advantages, like: </p>
<ul>
<li>allowing the servers to function as credential issuing authorities,
<li>allowing the servers to function as credential issuing authorities,
</li>
<li>allowing the servers to function as policy enforcement points. </li>
</ul>
<p>Unfortunately, such systems have significant disadvantages when one considers the nature of instant messaging: </p>
<ul>
<li>Many servers may be un-trusted, public servers.
<li>Many servers may be un-trusted, public servers.
</li>
<li>In many conversation communities, decisions of trust and membership can only be adequately defined by the members themselves.
<li>In many conversation communities, decisions of trust and membership can only be adequately defined by the members themselves.
</li>
<li>In many conversation communities, membership in the community changes in real time based upon the dynamics of the conversation.
<li>In many conversation communities, membership in the community changes in real time based upon the dynamics of the conversation.
</li>
<li>In many conversation communities, the data classification of the conversation changes in real time based upon the dynamics of the conversation. </li>
</ul>
@ -120,7 +120,7 @@
<section2 topic="2.2 Environmental Considerations">
<p>Any new IM security protocol must integrate smoothly into the existing IM environment, and it must also recognize the nature of the transactions performed by conversation participants. These considerations are especially important: </p>
<ul>
<li>dynamic communities. The members of a community are defined in near real time by the existing members.
<li>dynamic communities. The members of a community are defined in near real time by the existing members.
</li>
<li>dynamic conversations. Conversations may involve any possible subset of the entire set of community members. </li>
</ul>
@ -130,7 +130,7 @@
<section2 topic="Usability">
<p>Given the requirement to place the responsibility for the protection of conversation data in the hands of the participants, it is imperative to address some fundamental usability issues: </p>
<ul>
<li>Overall ease of use is a requirement. For protocol purposes, one implication is that some form of authentication via passphrases is necessary. While we recognize that this can have appalling consequences, especially when we realize that a passphrase may be shared by all of the community members, we also recognize its utility.
<li>Overall ease of use is a requirement. For protocol purposes, one implication is that some form of authentication via passphrases is necessary. While we recognize that this can have appalling consequences, especially when we realize that a passphrase may be shared by all of the community members, we also recognize its utility.
</li>
<li>PKIs are well established in many large organizations, and some communities will prefer to rely on credentials issued from these authorities. We must allow the use of existing PKI credentials and trust models rather than impose closed, XMPP-specific credentials.
</li>
@ -140,17 +140,17 @@
<section2 topic="Development And Deployment">
<p>To successfully integrate into the existing XMPP environment, an extension protocol for security must satisfy the following: </p>
<ul>
<li>It must be an optional extension of the existing XMPP protocol.
<li>It must be an optional extension of the existing XMPP protocol.
</li>
<li>It must be transparent to existing XMPP servers.
<li>It must be transparent to existing XMPP servers.
</li>
<li>It must function gracefully in cases where some community members are not running a user agent that supports the protocol.
<li>It must function gracefully in cases where some community members are not running a user agent that supports the protocol.
</li>
<li>It must make good use of XML.
<li>It must make good use of XML.
</li>
<li>It must avoid encumbered algorithms.
<li>It must avoid encumbered algorithms.
</li>
<li>It must be straightforward to implement using widely available cryptographic toolkits.
<li>It must be straightforward to implement using widely available cryptographic toolkits.
</li>
<li>It must not require a PKI. </li>
</ul>
@ -377,7 +377,7 @@
</ul>
<p>This key agreement protocol is used to establish a shared key with an assigned identifier and associated identities for two parties. The resulting common keying information state comprise a key name, secret keying material, the identification of the two parties, and three algorithms for use during authentication:</p>
<ul>
<li>encryption for privacy,
<li>encryption for privacy,
</li>
<li>hashing for protecting the integrity of message and for authentication of message fields
</li>
@ -485,14 +485,14 @@
<section4 topic="Initiator request Security Association parameters">
<p>The intitiator uses a &lt;SecurityAssociation/&gt; element in the request to list all the EHA algorithms that it supports. In addition it provides its own DH ephemeral public key.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initiator cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value is used as the originator key name for the security association.</li>
</ul>
<ul>
<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
</li>
</ul>
<p>These values are then used to prepare the XML element; this element is transmitted via the existing XMPP iq mechanism: </p>
@ -525,15 +525,15 @@
<section4 topic="Responder select Security Association parameters">
<p>The responder will reply to the request by sending out its own selcted EHA algorithms that will be used in the remainign transaction. </p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The responder cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value is used as the recipient key name for the security association..
</li>
<li>The algorithms attributes are checked against the values supported by the user agent. If the receiver is not able to select one set out of the proposed algorithms, an error code 406-Unacceptable is returned.
</li>
<li>The desired confidentiality and HMAC cryptographic algorithms are selected from the proposed set. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
<li>The desired confidentiality and HMAC cryptographic algorithms are selected from the proposed set. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
<li>The desired authentication algorithm is selected from the proposed set. The manner in which this algorithm is selected and all related policy issues are outside the scope of this specification. In the digital signature case, the responder's end-entity certificate MUST be issued by one of the trusted CAs listed in the session1 PDU or by the same issuer as the initiator's end-entity certificate. If the responder does not have acceptable credentials, an error code of 401-Unuthorized occurs.
<li>The desired authentication algorithm is selected from the proposed set. The manner in which this algorithm is selected and all related policy issues are outside the scope of this specification. In the digital signature case, the responder's end-entity certificate MUST be issued by one of the trusted CAs listed in the session1 PDU or by the same issuer as the initiator's end-entity certificate. If the responder does not have acceptable credentials, an error code of 401-Unuthorized occurs.
</li>
</ul>
@ -558,7 +558,7 @@
<section4 topic="Initiator provides its ephemeral public key">
<p>The intitiator provides its own DH ephemeral public key.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are used as the originator key name and the recipient key name for the security association..
</li>
@ -592,11 +592,11 @@
<section4 topic="Responder provides its ephemeral public key">
<p>The responder check the validity of the parameters and eventualy replies with its own DH ephemeral public key.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 406 - Unacceptable .
</li>
<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
</li>
<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded. </li>
</ul>
@ -626,9 +626,9 @@
<section4 topic="Initiator provides its encrypted nonce">
<p>The intitiator provides its nonce encrypted with the agreed algorithm and the public key of the responder.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
</li>
<li>The initiator nonce is prepared by first generating a string of 20 random octets (160 random bits). The nonce is then encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters. </li>
</ul>
@ -663,23 +663,23 @@
<section4 topic="Responder provides its encrypted nonce">
<p>The responder replies with the concatenation of its own nonce and the initiator nonce encrypted with the agreed algorithm and the public key of the initiator. The packet is authenticated using the agreed signature algorithm.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 401 - Unauthorized.
</li>
<li>The initiator nonce is decrypted using the responder private key.
</li>
<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). It is then apended to the initiator nonce and the result encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters.
<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). It is then apended to the initiator nonce and the result encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters.
</li>
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
<li>Kir = hmac (0, initiator's nonce | responder's nonce)
<li>Kir = hmac (0, initiator's nonce | responder's nonce)
</li>
<li>EHAs = (Encryption algorithm URI | Digest algorithm URI | Signature algorithm URI)
</li>
<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
</li>
</ol>
<ul>
@ -709,9 +709,9 @@
</EncryptedData>
</KA-Nonce>
</KeyAgreement>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignaturetValue>
... encoded signature value
@ -724,31 +724,31 @@
<section4 topic="Initiator authenticate the final agreement">
<p>The initiator authenticate the keying material using the agreed signature algorithm.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
</li>
<li>The concatenation of the responder and initiator nonce is decrypted using the initiator private key. The original initiator nonce is compared to the result. An invalid nonce results in aborting the procedure. Otherwise the result is used to generate Kir
</li>
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
<li>Kir = hmac (0, initiator's nonce | responder's nonce)
<li>Kir = hmac (0, initiator's nonce | responder's nonce)
</li>
<li>EHAs = (Encryption algorithm URI | Digest algorithm URI | Signature algorithm URI)
</li>
<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
</li>
</ol>
<ul>
<li>The authenticator is verified. A failure results in aborting the procedure.
</li>
<li>Based on the selected authentication algorithm, the initiator&#8217;s authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator&#8217;s authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
</li>
</ol>
@ -763,10 +763,10 @@
<KeyName>324A...BF24</KeyName>
</RecipientKeyInfo>
</SecurityAssociation>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignaturetValue>
<p>... encoded signature value</p>
@ -779,15 +779,15 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder checks the final agreement">
<p>The responder acknowledge the keying material.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 401 - Unauthorized.
</li>
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
</li>
</ol>
<ul>
@ -804,21 +804,21 @@ xmldsig-core-schema.xsd">
<section4 topic="Initiator provides all Security Association parameters">
<p>The intitiator uses &lt;SecurityAssociation/&gt; element in the request to list all the EHA algorithms that it supports. In addition it provides its own DH ephemeral public key. The message is signed with its own private key.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initiator cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value will be used as identifier for the initiator leg of the security association.
</li>
<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
</li>
<li>A Diffie-Hellman group is selected. The appropriate values for g and p will be used to generate the initiator's public key.
</li>
<li>An ephemeral private key, x, is generated using g and p for the selected group. This key MUST be generated using an appropriate random number source. The corresponding public key, g^x, is generated and encoded.
<li>An ephemeral private key, x, is generated using g and p for the selected group. This key MUST be generated using an appropriate random number source. The corresponding public key, g^x, is generated and encoded.
</li>
<li>The initiator nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
</li>
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -855,9 +855,9 @@ xmldsig-core-schema.xsd">
<p>... encoded initiator nonce value>
</KA-Nonce>
</KeyAgreement>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignatureValue>
<p>... encoded initiator signature value</p>
@ -870,11 +870,11 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder respond to Security Association parameters">
<p>The responder will reply to the request by acknowledging the selected EHA algorithms. In addition, it provides its own DH ephemeral public key. The message is signed with its own private key.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
</li>
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -888,11 +888,11 @@ xmldsig-core-schema.xsd">
</li>
<li>The responder cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value will be used as identifier for the responder leg of the security association.
</li>
<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded.
<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded.
</li>
<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
</li>
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -927,10 +927,10 @@ xmldsig-core-schema.xsd">
<p>... encoded responder nonce value>
</KA-Nonce>
</KeyAgreement>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignatureValue>
<p>... encoded responder signature value</p>
@ -943,9 +943,9 @@ xmldsig-core-schema.xsd">
<section4 topic="Initiator authenticate the final agreement">
<p>The initiator authenticate the keying material using the agreed signature algorithm.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -957,7 +957,7 @@ xmldsig-core-schema.xsd">
<ul>
<li>The authenticator is verified. A failure results in the procedure being aborted.
</li>
<li>Based on the selected authentication algorithm, the authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -979,10 +979,10 @@ xmldsig-core-schema.xsd">
<KeyName>324A...BF24</KeyName>
</RecipientKeyInfo>
</SecurityAssociation>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignaturetValue>
<p>... encoded signature value</p>
@ -994,9 +994,9 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder check the final agreement">
<p>The responder acknowledge the keying material.</p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -1031,28 +1031,28 @@ xmldsig-core-schema.xsd">
<section3 topic="Generating And Sending a Conversation Key Transport PDU">
<p>The Key Transport assumes that a security association be negotiated for the purpose of securely transporting conversation keys. The sender's user agent employs the following algorithm to generate the keyTransport PDU: </p>
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants who negotiated the security association, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants who negotiated the security association, respectively.
</li>
<li>The security association identifier is assembled.
<li>The security association identifier is assembled.
</li>
<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the integrity key sKEYID_a , is wrapped in instances of xenc:EncryptedKey as follows:
<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the integrity key sKEYID_a , is wrapped in instances of xenc:EncryptedKey as follows:
</li>
</ul>
<ol>
<li>The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
<li>The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
</li>
<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT be present.
<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT be present.
</li>
<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid symmetric key wrap algorithm. Furthermore, the algorithm MUST be the same as was negotiated for the security association.
<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid symmetric key wrap algorithm. Furthermore, the algorithm MUST be the same as was negotiated for the security association.
</li>
<li>The ds:KeyInfo element MUST NOT be present. The key to use is the shared secret KEY of the negotiated security association.
<li>The ds:KeyInfo element MUST NOT be present. The key to use is the shared secret KEY of the negotiated security association.
</li>
<li>The xenc:ContainedKeyName element MUST be present.
<li>The xenc:ContainedKeyName element MUST be present.
</li>
<li>The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice. </li>
</ol>
<ul>
<li>The HMAC is computed using KEY of the negotiated security association. A digital signature requires calculating:
<li>The HMAC is computed using KEY of the negotiated security association. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -1066,7 +1066,7 @@ xmldsig-core-schema.xsd">
<query xmlns="xmpp:sec">
<SecurityAssociation id="negotiated SA id"/>
<KeyTransport>
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-enc&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@ -1076,7 +1076,7 @@ xmldsig-core-schema.xsd">
</CipherValue>
</CipherData>
</EncryptedKey>
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-auth&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@ -1086,7 +1086,7 @@ xmldsig-core-schema.xsd">
</CipherValue>
</CipherData>
</EncryptedKey>
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-dig&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@ -1097,10 +1097,10 @@ xmldsig-core-schema.xsd">
</CipherData>
</EncryptedKey>
</KeyTransport>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@ -1117,13 +1117,13 @@ xmldsig-core-schema.xsd">
<section3 topic="Receiving and Processing the Conversation Key Transport PDU">
<p>The receiver's user agent employs the following algorithm to process each KeyTransport PDU: </p>
<ul>
<li>The values of initiator, responder, and security association id MUST indicate an existing security association. An invalid security association results in an error of 401 - Unauthorized.
<li>The values of initiator, responder, and security association id MUST indicate an existing security association. An invalid security association results in an error of 401 - Unauthorized.
</li>
<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the intergrity key sKEYID_a, is unwrapped. Any failures result in an error code of 406-Unacceptable.
<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the intergrity key sKEYID_a, is unwrapped. Any failures result in an error code of 406-Unacceptable.
</li>
<li>The body of the HMAC element is decoded into the actual HMAC octet string.
<li>The body of the HMAC element is decoded into the actual HMAC octet string.
</li>
<li>The HMAC is computed using KEY of the security association. A digital signature requires calculating:
<li>The HMAC is computed using KEY of the security association. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -1131,7 +1131,7 @@ xmldsig-core-schema.xsd">
</li>
</ol>
<ul>
<li>The HMAC is validated. An invalid HMAC results in an error code of 406-Unacceptable.
<li>The HMAC is validated. An invalid HMAC results in an error code of 406-Unacceptable.
</li>
<li>The keys are added to the user agent's key store. </li>
</ul>
@ -1179,12 +1179,12 @@ xmldsig-core-schema.xsd">
</section3>
<section3 topic="Other Public Keys Transport">
<ul>
<li>The values of initiator and responder MUST be the JIDs of the two participants in the exchange, respectively.
<li>The values of initiator and responder MUST be the JIDs of the two participants in the exchange, respectively.
</li>
<li>The payload, which consists of the public key of the responder is assembled. </li>
</ul>
<ul>
<li>The SIGN is computed using the private key of the responder. A digital signature requires calculating:
<li>The SIGN is computed using the private key of the responder. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -1204,9 +1204,9 @@ xmldsig-core-schema.xsd">
</RSAKeyValue>
</KeyInfo>
</KeyTransport>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@ -1228,7 +1228,7 @@ xmldsig-core-schema.xsd">
<section2 topic="Message Protection Mechanism">
<p>A protected message is defined as a traditional XMPP message whose body content is extended to include the transport of a cryptographically protected message body. The two key features are: </p>
<ul>
<li>the usual body element contains some arbitrary text.
<li>the usual body element contains some arbitrary text.
</li>
<li>the message contains a XMPP x element defining the xmpp:sec namespace; this element transports the protected message. </li>
</ul>
@ -1238,24 +1238,24 @@ xmldsig-core-schema.xsd">
<section2 topic="Generating And Sending the Protected Message PDU">
<p>The sender's user agent employs the following algorithm to generate the protected Message PDU: </p>
<ul>
<li>The security association identifier is assembled.
<li>The security association identifier is assembled.
</li>
<li>The actual message body is encoded into a character string corresponding to a XMPP message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows: </li>
</ul>
<ol>
<li>The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
<li>The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
</li>
<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT be present.
<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT be present.
</li>
<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid block encryption algorithm.
<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid block encryption algorithm.
</li>
<li>The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality key indicated by the convId attribute.
<li>The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality key indicated by the convId attribute.
</li>
<li>The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice. </li>
</ol>
<ul>
<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
</li>
</ul>
<ol>
@ -1270,7 +1270,7 @@ xmldsig-core-schema.xsd">
The real body is protected.
</body>
<x xmlns="xmpp:security">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<KeyInfo>
<KeyName>A32F2...45A324A...BF24-enc</KeyName>
@ -1282,9 +1282,9 @@ The real body is protected.
</CipherValue>
</CipherData>
</EncryptedData>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@ -1303,13 +1303,13 @@ The real body is protected.
<section2 topic="Receiving and Processing the Protected Message PDU">
<p>The receiver's user agent employs the following algorithm to process each protectedMessage PDU: </p>
<ul>
<li>The values of initiator, responder, and key name MUST indicate an existing security association. An invalid security association results in an error of 406-Unacceptable.
<li>The values of initiator, responder, and key name MUST indicate an existing security association. An invalid security association results in an error of 406-Unacceptable.
</li>
<li>The payload, which consists of the actual message body, is unwrapped. Any failures result in an error code of 406-Unacceptable.
<li>The payload, which consists of the actual message body, is unwrapped. Any failures result in an error code of 406-Unacceptable.
</li>
<li>The body of the HMAC element is decoded into the actual HMAC octet string.
<li>The body of the HMAC element is decoded into the actual HMAC octet string.
</li>
<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
</li>
</ul>
<ol>

2
xep-0103.xml
View File

@ -138,7 +138,7 @@
<p>The sender starts with an SI request, using the semantics from XEP-0095:</p>
<example caption='Requesting SI transfer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>

6
xep-0104.xml
View File

@ -180,7 +180,7 @@
targetNamespace='http://jabber.org/protocol/url-data/scheme/http'
xmlns='http://jabber.org/protocol/url-data/scheme/http'
elementFormDefault='qualified'>
<xs:element name='auth'>
<xs:complexType>
<xs:attribute name='scheme' use='required' type='xs:string'/>
@ -196,7 +196,7 @@
</xs:element>
</xs:complexType>
</xs:element>
<xs:element name='cookie'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
@ -209,7 +209,7 @@
<xs:attribute name='version' use='optional' type='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='header'>
<xs:complexType>
<xs:simpleContent>

16
xep-0105.xml
View File

@ -82,11 +82,11 @@
<section1 topic='Examples'>
<example caption='Profile Usage in Stream Initiation Offer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si
xmlns='http://jabber.org/protocol/si'
<si
xmlns='http://jabber.org/protocol/si'
id='a0'
profile='http://jabber.org/protocol/si/profile/tree-transfer'>
<tree
<tree
xmlns='http://jabber.org/profile/si/profile/tree-transfer'
numfiles='9'
size='80500'>
@ -132,7 +132,7 @@
]]></example>
<example caption='Subsequent File Transfer Offer'><![CDATA[
<iq type='set' id='offer2' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='ft1'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -169,7 +169,7 @@
targetNamespace='http://jabber.org/protocol/si/profile/tree-transfer'
xmlns='http://jabber.org/protocol/si/profile/tree-transfer'
elementFormDefault='qualified'>
<xs:element name='tree'>
<xs:complexType>
<xs:attribute name='numfiles' use='required' type='xs:integer'/>
@ -177,7 +177,7 @@
<xs:element ref='directory' minOccurs='0' maxOccurs='1'/>
</xs:complexType>
</xs:element>
<xs:element name='directory'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
@ -185,14 +185,14 @@
<xs:element ref='file' minOccurs='0' maxOccurs='unbounded'/>
</xs:complexType>
</xs:element>
<xs:element name='file'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
<xs:attribute name='sid' use='required' type='xs:string'/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section1>

4
xep-0107.xml
View File

@ -122,7 +122,7 @@
]]></example>
<p>The mood is then delivered to all subscribers:</p>
<example caption='Mood is Delivered to All Subscribers'><![CDATA[
<message
<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -152,7 +152,7 @@
</iq>
]]></example>
<example caption='Empty Mood Information is Delivered to All Subscribers'><![CDATA[
<message
<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>

10
xep-0108.xml
View File

@ -111,7 +111,7 @@
<section2 topic='Pubsub Transport' anchor='proto-pubsub'>
<p>Activity information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because activity 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>
<example caption='User Publishes Activity'><![CDATA[
<iq type='set'
<iq type='set'
from='juliet@capulet.lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -130,8 +130,8 @@
]]></example>
<p>The activity is then delivered to all subscribers:</p>
<example caption='Activity is Delivered to All Subscribers'><![CDATA[
<message
from='juliet@capulet.lit'
<message
from='juliet@capulet.lit'
to='romeo@montague.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/activity'>
@ -162,7 +162,7 @@
</iq>
]]></example>
<example caption='Empty Activity Information is Delivered to All Subscribers'><![CDATA[
<message
<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -237,7 +237,7 @@
<li>taking_a_shower</li>
</ul>
</li>
<li>having_appointment</li>
<li>inactive

26
xep-0109.xml
View File

@ -79,7 +79,7 @@
is in effect.</li>
</ul>
<p>All these requirements are satisfied by &xep0163;, which is a subset of &xep0060;.</p>
<p>All these requirements are satisfied by &xep0163;, which is a subset of &xep0060;.</p>
</section1>
@ -104,7 +104,7 @@
out-of-office settings on a PEP node with the desired access model (such as Presence or Open). When
a user (or their client) sends presence containing CAPS (see &xep0115;) with an
entry for out-of-office to a contact with an out-of-office message, the user's
client is notified of the out-of-office message and may display, in a client-defined
client is notified of the out-of-office message and may display, in a client-defined
fashion, the out-of-office settings information.</p>
<p>Clients may rely on the PEP node for notifications of changes as well as
@ -131,7 +131,7 @@
]]></example>
<example caption='Server returns out-of-office settings'><![CDATA[
<iq type='result'
<iq type='result'
from='example.com'
id='get1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub>
@ -152,8 +152,8 @@
<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
the format specified by &xep0082;.</p>
the format specified by &xep0082;.</p>
<p>The &lt;message/> element contains the text of the message which the client may
display for the user (when appropriate).</p>
@ -172,9 +172,9 @@
of 'current' to the out-of-office node:</p>
<example caption='Publishing new out-of-office settings'><![CDATA[
<iq type='set'
from='user@example.com/client'
to='example.com'
<iq type='set'
from='user@example.com/client'
to='example.com'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:ooo:0'>
@ -193,9 +193,9 @@
]]></example>
<example caption='Out-of-office settings published successfully'><![CDATA[
<iq type='result'
from='example.com'
to='user@example.com/client'
<iq type='result'
from='example.com'
to='user@example.com/client'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:ooo:0'>
@ -216,7 +216,7 @@
<p>And by design, PEP sends a notification to all the user's resources.</p>
<example caption="PEP node notification sent to user"><![CDATA[
<message from='user@example.com'
<message from='user@example.com'
id='notification_1781477179'
to='user@example.com/client' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -307,7 +307,7 @@
<section1 topic='Server requirements'>
<p>A server implementing out-of-office messages MUST implement
&xep0163;.</p>
&xep0163;.</p>
</section1>
<section1 topic='Security Considerations'>
<p>None yet defined.</p>

36
xep-0111.xml
View File

@ -77,7 +77,7 @@
<section1 topic="Introduction" anchor='intro'>
<p><em>Note Well: This proposal has been retracted by the authors in favor of &xep0166;.</em></p>
<p>The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &xmppcore;).
<note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
<note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
In particular, TINS provides an XMPP representation of standard session management semantics such as those provided by the Session Initiation Protocol (SIP; see &rfc3261;). As a result, native XMPP clients that support TINS can negotiate out-of-band multimedia sessions (e.g., use of the Real-Time Transport Protocol or RTP; see &rfc3550;) and XMPP services that support TINS can easily interoperate with SIP services through gateways.</p>
</section1>
<section1 topic="Requirements" anchor='reqs'>
@ -89,7 +89,7 @@
</ol>
</section1>
<section1 topic="Protocol" anchor='protocol'>
<p>TINS exchanges are completed by sending &MESSAGE; stanzas containing a child &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace.
<p>TINS exchanges are completed by sending &MESSAGE; stanzas containing a child &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace.
<note>While it may seem that the semantics of &IQ; stanzas are more appropriate, <cite>RFC 3261</cite> allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in <cite>RFC 6120</cite>.</note>
In order to track the structure of the TINS "conversation", the &THREAD; child of &MESSAGE; MAY also be included. The &lt;tins/&gt; element MUST possess a 'method' attribute, whose value SHOULD be either an IANA-registered value for a SIP method or "result", as described below. The following SIP methods will probably be used most frequently in TINS interactions:</p>
<ul>
@ -97,7 +97,7 @@
<li><p>ACK -- Used by the initiator to tell the invitee that an out-of-band session has been established.</p></li>
<li><p>BYE -- Used by either side of the conversation to terminate the transaction. This message SHOULD cause all resources associated with this transaction to be freed, and any associated network connections to be terminated.</p></li>
</ul>
<p>The SDP data itself is included as the XML character data of an &lt;sdp/&gt; child of the &lt;tins/&gt; element, qualifed by the 'urn:ietf:rfc:2327' namespace (this is consistent with &rfc2648;).
<p>The SDP data itself is included as the XML character data of an &lt;sdp/&gt; child of the &lt;tins/&gt; element, qualifed by the 'urn:ietf:rfc:2327' namespace (this is consistent with &rfc2648;).
<note>The &lt;sdp/&gt; element is qualified by a separate namespace because it may be desirable for TINS to support other formats (such as SDPng) in the future; these can then be added without changing the XML schema for TINS.</note>
Any restricted XML characters in the SDP data (i.e., &amp; &apos; &lt; &gt; &quot;) MUST be properly escaped when contained in the XML character data of the &lt;sdp/&gt; element (for example, the ' character MUST be escaped to &amp;apos;). It is the responsibility of the XMPP recipient or translating gateway to unescape these restricted characters for processing.</p>
<p>The request stanza MAY also include either or both of the following:</p>
@ -116,8 +116,8 @@
<p>The following XMPP stanzas could be used to initiate a voice call. The 'from' addresses will usually be added by the XMPP server or relevant gateway, but are shown here for the sake of clarity. Note the inclusion of SHIM headers and extended addresses.</p>
<example caption='Step 1: A sends an invite to B'><![CDATA[
<message
from='A@example.com/work'
to='B@example.com/laptop'
from='A@example.com/work'
to='B@example.com/laptop'
id='tins01'>
<thread>1234@hostA.example.com</thread>
<tins method='INVITE' xmlns='http://jabber.org/protocol/tins'>
@ -146,8 +146,8 @@
]]></example>
<example caption='Step 2: B tells A that it is trying'><![CDATA[
<message
from='B@example.com/laptop'
to='A@example.com/work'
from='B@example.com/laptop'
to='A@example.com/work'
id='tins01'>
<thread>1234@hostA.example.com</thread>
<tins method='result'
@ -165,8 +165,8 @@
]]></example>
<example caption='Step 3: B tells A that it is ringing'><![CDATA[
<message
from='B@example.com/laptop'
to='A@example.com/work'
from='B@example.com/laptop'
to='A@example.com/work'
id='tins01'>
<tins method='result'
code='180'
@ -183,11 +183,11 @@
]]></example>
<example caption='Step 4: B sends an updated description to A'><![CDATA[
<message
from='B@example.com/laptop'
to='A@example.com/work'
from='B@example.com/laptop'
to='A@example.com/work'
id='tins02'>
<thread>1234@hostA.example.com</thread>
<tins method='result'
<tins method='result'
code='200'
xmlns='http://jabber.org/protocol/tins'>
<sdp xmlns='urn:ietf:rfc:2327'>
@ -217,8 +217,8 @@
]]></example>
<example caption='Step 5: A sends an acknowledgement to B'><![CDATA[
<message
from='A@example.com/work'
to='B@example.com/laptop'
from='A@example.com/work'
to='B@example.com/laptop'
id='tins02'>
<thread>1234@hostA.example.com</thread>
<tins method='ACK' xmlns='http://jabber.org/protocol/tins'/>
@ -234,8 +234,8 @@
]]></example>
<example caption='Step 6: B hangs up'><![CDATA[
<message
from='B@example.com/laptop'
to='A@example.com/work'
from='B@example.com/laptop'
to='A@example.com/work'
id='tins03'>
<thread>1234@hostA.example.com</thread>
<tins method='BYE' xmlns='http://jabber.org/protocol/tins'/>
@ -251,8 +251,8 @@
]]></example>
<example caption='Step 7: A acknowledges the hang up'><![CDATA[
<message
from='A@example.com/work'
to='B@example.com/laptop'
from='A@example.com/work'
to='B@example.com/laptop'
id='tins03'>
<thread>1234@hostA.example.com</thread>
<tins method='result'

6
xep-0112.xml
View File

@ -80,7 +80,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>NOTE WELL: The protocol defined herein has been folded into &xep0080;.</em></p>
<p>This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>XEP-0080</cite>.</p>
<p>This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>XEP-0080</cite>.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>Information about the user's location is provided by the user and propagated on the network by the user's client. The information is structured by means of an &lt;physloc/&gt; element that is qualified by the 'http://jabber.org/protocol/physloc' namespace. The location information itself is provided as the XML character data of the following children of the &lt;physloc/&gt; element:</p>
@ -212,8 +212,8 @@
<td align='center'>&lt;Street/&gt;
<note>The IMPS specification also enables one to define an intersection (e.g., "Broadway and 34th Street") as the combination of a &lt;Crossing1/&gt; element (e.g., "Broadway") and a &lt;Crossing2/&gt; element (e.g., "34th Street"). To map from IMPS to Jabber, an application SHOULD map such a combination to one Jabber/XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;A6/&gt;
<note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to Jabber, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one Jabber/XMPP &lt;street/&gt; element.</note>
<td align='center'>&lt;A6/&gt;
<note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to Jabber, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one Jabber/XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;STREET/&gt;</td>
</tr>

44
xep-0113.xml
View File

@ -71,7 +71,7 @@
<section2 topic='Single whiteboard message'>
<p>Typically the user right-clicks on the destination contact and will select a "whiteboard message" option. The client will show a dialog where the user can create the drawing. It is up to the implementation to decide whether the user can include text in the message as well. Upon clicking a send button the client will close the dialog and send the following message:</p>
<example caption='Single whiteboard message'><![CDATA[
<message
<message
from='painter@shakespeare.lit'
to='timon@shakespeare.lit/hall'>
<body>A piece of painting, which I do beseech your lordship to accept.</body>
@ -88,7 +88,7 @@
<section2 topic='Whiteboard chat session'>
<p>A more typical use case is where two clients share a whiteboard. Again the user will right click on the destination and will select a "whiteboard chat" option. The client will present a dialog where the user can create a drawing. Upon clicking a send button or releasing the mouse button, the client will send the following message:</p>
<example caption='Initiating a whiteboard chat session'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'
type='chat'>
@ -101,26 +101,26 @@
]]></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>
<example caption='Continuing a whiteboard chat session'><![CDATA[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
<thread>c357e044c676cc5e3c729d07544c87b58a366dba</thread>
<x xmlns='http://jabber.org/protocol/swb'>
<path d='M 32 41 L 33 40 33 39 34 38 34 37 35 36 35 34 36 33 37
32 38 31 38 30 39 30 40 28 41 27 42 26 43 26 44 25 45
24 46 24 48 23 50 22 52 21 53 21 54 21 55 21 55 20 56
20 58 20 59 20 60 20 61 20 62 20 63 20 64 20 65 20 66
20 67 20 68 20 69 20 69 21 70 21 71 22 72 23 72 24 73
25 73 26 73 27 73 28 73 29 73 30 74 30 74 31 74 32 75
33 75 34 75 35 75 36 75 37 75 38 75 39 75 40 75 41 75
43 75 44 75 46 75 47 75 48 75 49 75 50 74 52 74 53 74
54 73 55 72 55 72 57 72 58 71 58 70 60 69 61 69 63 68
64 67 64 67 65 67 66 66 67 65 67 65 69 64 70 64 71 63
72 62 73 62 74 62 75 61 75 60 76 60 77 59 77 59 78 59
79 58 79 58 80 58 81 58 82 57 82 57 83 57 84 57 86 57
87 56 87 56 88 56 89 55 89 55 90 55 91 55 92 54 93 54
94 54 95 54 96 M 55 113 L 54 113 53 113 52 113 51 113
<path d='M 32 41 L 33 40 33 39 34 38 34 37 35 36 35 34 36 33 37
32 38 31 38 30 39 30 40 28 41 27 42 26 43 26 44 25 45
24 46 24 48 23 50 22 52 21 53 21 54 21 55 21 55 20 56
20 58 20 59 20 60 20 61 20 62 20 63 20 64 20 65 20 66
20 67 20 68 20 69 20 69 21 70 21 71 22 72 23 72 24 73
25 73 26 73 27 73 28 73 29 73 30 74 30 74 31 74 32 75
33 75 34 75 35 75 36 75 37 75 38 75 39 75 40 75 41 75
43 75 44 75 46 75 47 75 48 75 49 75 50 74 52 74 53 74
54 73 55 72 55 72 57 72 58 71 58 70 60 69 61 69 63 68
64 67 64 67 65 67 66 66 67 65 67 65 69 64 70 64 71 63
72 62 73 62 74 62 75 61 75 60 76 60 77 59 77 59 78 59
79 58 79 58 80 58 81 58 82 57 82 57 83 57 84 57 86 57
87 56 87 56 88 56 89 55 89 55 90 55 91 55 92 54 93 54
94 54 95 54 96 M 55 113 L 54 113 53 113 52 113 51 113
49 114 49 115 48 115 47 115 47 116 47 117 46 117 45 117
45 118 45 120 45 121 45 123 45 124 45 125 45 127 45 128
45 130 46 131 46 132 46 133 47 133 47 134 48 134 49 134
@ -135,7 +135,7 @@
<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>
<example caption='Moving a path'><![CDATA[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
@ -148,7 +148,7 @@
<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>
<example caption='Deleting a path'><![CDATA[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
@ -163,7 +163,7 @@
<section2 topic='Conference room whiteboard'>
<p>The final use case is the one where multiple users, gathered in a conference room, share a single whiteboard. Messages will typically look like this:</p>
<example caption='Conference room whiteboard'><![CDATA[
<message
<message
from='nestor@shakespeare.lit'
to='plains@conference.shakespeare.lit'
type='groupchat'>
@ -196,7 +196,7 @@
};
for (int i = 0 ; sHersheyFontData ['A'][2*i+2] != 0 ; i++) {
// read a new coordinate pair
// read a new coordinate pair
POINT myPoint = {sHersheyFontData ['A'][2*i+2]-'R', sHersheyFontData ['A'][2*i+2+1]-'R')};
// test for the special case pen up
if (myPoint.x == -50 && myPoint.y == 0) {
@ -277,7 +277,7 @@
<!ELEMENT path EMPTY >
<!ATTLIST path d CDATA #REQUIRED
stroke CDATA #IMPLIED
stroke-width CDATA #IMPLIED
stroke-width CDATA #IMPLIED
id CDATA #IMPLIED >
<!ELEMENT move EMPTY >
<!ATTLIST move id CDATA #REQUIRED

4
xep-0114.xml
View File

@ -100,7 +100,7 @@
from='plays.shakespeare.lit'
id='3BF96D32'>
]]></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>
<example caption='Component sends handshake element'><![CDATA[
<handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake>
@ -113,7 +113,7 @@
<li>Convert the hash output to all lowercase characters.</li>
</ol>
<p>If the credentials supplied by the initiator are not valid, the receiver MUST close the stream and the underlying TCP connection, and SHOULD return a &lt;not-authorized/&gt; stream error.</p>
<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[
<handshake/>
]]></example>

28
xep-0115.xml
View File

@ -138,7 +138,7 @@
<p>It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:</p>
<ul>
<li>Showing a different set of icons depending on the capabilities of other entities.</li>
<li>Not sending &xep0071; or other rich content to plaintext clients such as cell phones.</li>
<li>Not sending &xep0071; or other rich content to plaintext clients such as cell phones.</li>
<li>Allowing the initiation of a Voice over IP (VoIP) session only to clients that support &xep0166; and &xep0167;.</li>
<li>Not showing a "Send a File" button if another user's client does not support &xep0096;.</li>
<li>Filtering &xep0060; notifications based on advertised subscriber interests.</li>
@ -150,7 +150,7 @@
<p>Imagine that you are a Shakespearean character named Juliet and one of your contacts, a handsome fellow named Romeo, becomes available. His client wants to publish its capabilities, and does this by adding to its presence packets a &lt;c/&gt; element with special attributes. As a result, your client receives the following presence packet:</p>
<code><![CDATA[
<presence from='romeo@montague.lit/orchard'>
<c xmlns='http://jabber.org/protocol/caps'
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
@ -159,9 +159,9 @@
<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>
<code><![CDATA[
<iq from='juliet@capulet.lit/chamber'
<iq from='juliet@capulet.lit/chamber'
id='disco1'
to='romeo@montague.lit/orchard'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
@ -169,9 +169,9 @@
]]></code>
<p>The response is:</p>
<code><![CDATA[
<iq from='romeo@montague.lit/orchard'
<iq from='romeo@montague.lit/orchard'
id='disco1'
to='juliet@capulet.lit/chamber'
to='juliet@capulet.lit/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
@ -186,7 +186,7 @@
<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[
<presence from='nurse@capulet.lit/chamber'>
<c xmlns='http://jabber.org/protocol/caps'
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
@ -196,7 +196,7 @@
<p>On the other hand, for a person with the following presence ...</p>
<code><![CDATA[
<presence from='benvolio@capulet.lit/230193'>
<c xmlns='http://jabber.org/protocol/caps'
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
@ -205,7 +205,7 @@
<p>... or the following presence ...</p>
<code><![CDATA[
<presence from='bard@shakespeare.lit/globe'>
<c xmlns='http://jabber.org/protocol/caps'
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
@ -331,7 +331,7 @@
<code>
&lt;iq from='benvolio@capulet.lit/230193'
id='disco1'
to='juliet@capulet.lit/chamber'
to='juliet@capulet.lit/chamber'
type='result'&gt;
&lt;query xmlns='http://jabber.org/protocol/disco#info'
node='http://psi-im.org#q07IKJEyjvHSyhy//CH0CxmKi8w='&gt;
@ -460,9 +460,9 @@
<p>An application (the "requesting entity") can learn what features another entity supports by sending a disco#info request (see <cite>XEP-0030</cite>) to the entity that generated the caps information (the "generating entity").</p>
<example caption='Disco#info request'><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='disco1'
to='romeo@montague.lit/orchard'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
@ -476,9 +476,9 @@
<p>The generating entity then returns all of the capabilities it supports.</p>
<example caption='Disco#info response'><![CDATA[
<iq from='romeo@montague.lit/orchard'
<iq from='romeo@montague.lit/orchard'
id='disco1'
to='juliet@capulet.lit/balcony'
to='juliet@capulet.lit/balcony'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>

2
xep-0117.xml
View File

@ -141,7 +141,7 @@
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>

4
xep-0119.xml
View File

@ -172,9 +172,9 @@ Service | Manager
<p>This document introduces no new security considerations above and beyond those defined in the documents on which it depends. Because publicly exposing some forms of extended presence information (e.g., geolocation information) may lead to unnecessary risks, care should be taken in setting the access model for the relevant pubsub nodes (minimally, an access model of "presence" to take advantage of the bidirectional authorization scheme inherent in XMPP presence subscriptions).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

2
xep-0120.xml
View File

@ -60,7 +60,7 @@
<p>The format defined herein uses a simple "key-value" structure. Although this may seem contrary to the XML basis of Jabber technologies, there are at least two good reasons for pursuing this approach:</p>
<ol>
<li><p>Using namespaced XML elements would force implementations to maintain a record of all namespaces and to differentiate those that define actionable protocols (e.g., 'http://jabber.org/protocol/si') from those that define informational metadata formats (e.g., 'http://purl.org/dc/elements/1.1'); the only way to do this would be to maintain an internal list of all possible namespaces that might be encountered by an application on the network.</p></li>
<li><p>Not all metadata formats that the Jabber community may want to use exist in stable XML representations (e.g., this is true of the vCard format) or in representations for which namespaces exist. In addition, some metadata formats (e.g., &foaf;) exist only in &w3rdf;, whose syntax is represented in XML but whose semantics impose a more complex structure that requires a specialized (non-XML) parser. As long as a clear mapping can be defined between such metadata formats and Jabber infobits, consistent information representation and exchange can be preserved.</p></li>
<li><p>Not all metadata formats that the Jabber community may want to use exist in stable XML representations (e.g., this is true of the vCard format) or in representations for which namespaces exist. In addition, some metadata formats (e.g., &foaf;) exist only in &w3rdf;, whose syntax is represented in XML but whose semantics impose a more complex structure that requires a specialized (non-XML) parser. As long as a clear mapping can be defined between such metadata formats and Jabber infobits, consistent information representation and exchange can be preserved.</p></li>
</ol>
</section1>
<section1 topic='Protocol'>

44
xep-0122.xml
View File

@ -140,8 +140,8 @@
<section3 topic='&lt;open/&gt; Validation' anchor='usercases-validation.open'>
<p>For "list-single" or "list-multi", to indicate that the user may enter a custom value (matching the datatype constraints) or choose from the predefined values, the &lt;validate/&gt; element shall contain an &lt;open/&gt; child element:</p>
<example caption='Open validation'><![CDATA[
<field var='evt.category'
type='list-single'
<field var='evt.category'
type='list-single'
label='Event Category'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:string'>
@ -161,7 +161,7 @@
<field var='evt.date' type='text-single' label='Event Date/Time'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:dateTime'>
<range min='2003-10-05T00:00:00-07:00'
<range min='2003-10-05T00:00:00-07:00'
max='2003-10-24T23:59:59-07:00'/>
</validate>
<value>2003-10-06T11:22:00-07:00</value>
@ -191,8 +191,8 @@
<section2 topic='Selection Ranges in "list-multi"' anchor='usecases-ranges'>
<p>For "list-multi", validation can indicate (via the &lt;list-range/&gt; element) that a minimum and maximum number of options should be selected and/or entered. This selection range MAY be combined with the other methods to provide more flexibility.</p>
<example caption='Selection Range validation'><![CDATA[
<field var='evt.notify-methods'
type='list-multi'
<field var='evt.notify-methods'
type='list-multi'
label='Notify me by'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:string'>
@ -225,7 +225,7 @@
<p>While all elements associated with this document MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.</p>
<p>The use of namespace prefixes is RECOMMENDED for large forms, to reduce the data size. To maintain the highest level of compatibility, implementations sending the form using prefixes SHOULD use the namespace prefix "xdv", and SHOULD declare the namespace prefix mapping in the ancestor &lt;x xmlns='jabber:x:data'/&gt; element:</p>
<example caption='Example of recommended namespace prefixing'><![CDATA[
<x xmlns='jabber:x:data'
<x xmlns='jabber:x:data'
xmlns:xdv='http://jabber.org/protocols/xdata-validate'
type='form'>
<title>Sample Form</title>
@ -264,7 +264,7 @@
<th>SHOULD NOT be Allowed</th>
<th>Display Suggestions</th>
</tr>
<tr>
<td>basic</td>
<td><ul>
@ -281,7 +281,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale</td>
</tr>
<tr>
<td>open</td>
<td><ul>
@ -297,7 +297,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale. For "text-multi" treat each value as a discrete entry (e.g. a user-entered list). For "list-multi" or "list-single", allow user to add/remove entries to select.</td>
</tr>
<tr>
<td>range</td>
<td><ul>
@ -311,7 +311,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale. For "text-single", allow user to increment/decrement through possible values. For "text-multi" treat each value as a discrete entry (e.g. a user-entered list). For "list-multi" or "list-single", allow user to add/remove entries to select.</td>
</tr>
<tr>
<td>regex</td>
<td><ul>
@ -488,7 +488,7 @@
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/xdata-validate'
@ -506,17 +506,17 @@
</xs:choice>
<xs:element ref='list-range' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='datatype'
type='xs:string'
use='optional'
<xs:attribute name='datatype'
type='xs:string'
use='optional'
default='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='basic' type='empty'/>
<xs:element name='open' type='empty'/>
<xs:element name='range'>
<xs:complexType>
<xs:simpleContent>
@ -527,24 +527,24 @@
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='regex' type='xs:string'/>
<xs:element name='list-range'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='min'
<xs:attribute name='min'
type='xs:unsignedInt'
use='optional'/>
<xs:attribute name='max'
<xs:attribute name='max'
type='xs:unsignedInt'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>

4
xep-0124.xml
View File

@ -252,7 +252,7 @@ first socket second socket
+-+
|
+-+ <-- empty body request
|X| socket opened --> ===
|X| socket opened --> ===
|-| |
| | new message out --> +-+
|-| <-- empty body response |X|
@ -291,7 +291,7 @@ first socket second socket
| +-+
| |
| empty body request --> +-+
| |X|
| |X|
| |-|
| | |
| | |

38
xep-0127.xml
View File

@ -63,7 +63,7 @@
<p>In the case of direct messages, the message stanza SHOULD have no 'type' attribute, but MAY have any defined type that is appropriate to the communications context (e.g., "groupchat" in a text conference). The &lt;alert/&gt; element SHOULD be the only child element of the message stanza, but other elements MAY be included as necessary (e.g., a &lt;body/&gt; child in the 'jabber:client' namespace providing a natural-language description of the alert). The 'id' attribute of the &MESSAGE; stanza MAY be set to the value of the CAP &lt;identifier/&gt; element.</p>
<p>The following example shows Example A.2 from the CAP specification sent as a direct message.</p>
<example caption='An Alert Sent as a Message'><![CDATA[
<message from='KSTO@NWS.NOAA.GOV'
<message from='KSTO@NWS.NOAA.GOV'
to='weatherbot@jabber.org'
id='KSTO1055887203'>
<alert xmlns='http://www.incident.com/cap/1.0'>
@ -82,10 +82,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@ -94,12 +94,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>
@ -138,10 +138,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@ -150,12 +150,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>
@ -191,10 +191,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@ -203,12 +203,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>

6
xep-0129.xml
View File

@ -137,18 +137,18 @@
Host: files.shakespeare.lit
Authorization: Digest username="juliet@capulet.com",
realm="xmpp",
nonce="ec2cc00f21f71acd35ab9be057970609",
nonce="ec2cc00f21f71acd35ab9be057970609",
uri="missive.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></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>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
from='files.shakespeare.lit'
from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<confirm xmlns='http://jabber.org/protocol/http-auth'

22
xep-0130.xml
View File

@ -349,16 +349,16 @@
</ol>
</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>All Users Remove Contact from Their WaitingLists
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</ol>
</li>
</ol>
</section3>
@ -604,7 +604,7 @@
<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>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
<message
<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
@ -646,12 +646,12 @@
to='user@service-provider.com'>
<body>Sorry, we cannot find this contact.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'
<item id='34567'
jid='contact@service-provider.com'
type='error'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
<error code='404'
<error code='404'
type='cancel'
xmlns='jabber:client'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -815,7 +815,7 @@
]]></example>
<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[
<message
<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'

4
xep-0131.xml
View File

@ -189,7 +189,7 @@
<p>The Distribute header enables a sender to specify whether the stanza may be further distributed by the recipient to other entities on the network. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT further distribute the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY further distribute the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". This header is semantically equivalent to the "Distribute" flag defined in &geoprivpol;. (The HTTP "Max-Forwards" header is not appropriate for this usage, since it defines proxy and gateway behavior rather than recipient behavior.) Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
</section2>
<section2 topic='Store' anchor='headers-store'>
<p>The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT store the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY store the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
<p>The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT store the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY store the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
</section2>
<section2 topic='TTL' anchor='headers-ttl'>
<p>It may be useful to specify that the information contained in a stanza is valid only for a limited period of time. Such is the function of the "TTL" header, the value of which is some number of seconds since the creation of the stanza. Note well that this header is purely informational and MUST NOT be used for routing or delivery of XML stanzas, since that function is already served by &xep0079;. A stanza that includes the "TTL" header SHOULD also include a "Created" header so that the recipient can properly process the stanza.</p>
@ -225,7 +225,7 @@
<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>
<example caption='An Urgent Message'><![CDATA[
<message
<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com'
type='chat'>

26
xep-0132.xml
View File

@ -43,7 +43,7 @@
<p>As defined in <cite>XMPP IM</cite>, presence stanzas of type "probe" are handled on behalf of the target entity by the entity's server. While normally these presence stanzas are generated by the requesting entity's server (e.g., when the requesting entity sends initial presence), the requesting entity itself (or, more precisely, its client) is allowed to generate presence stanzas of type "probe". In this document we make use of this ability to query the target entity's server regarding the entity's physical presence.</p>
<p>In the following example, a star-crossed lover pokes the server of his beloved to determine her physical presence (notice that the value of 'to' address lacks a resource identifier and therefore is a bare JID, not a full JID).</p>
<example caption='Poking via the server'><![CDATA[
<presence
<presence
type='probe'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
@ -53,28 +53,28 @@
]]></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>
<example caption='Server returns service unavailable error'><![CDATA[
<presence
<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='503' type='cancel'>
<service-unavailable
<service-unavailable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></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>
<example caption='Server returns forbidden error'><![CDATA[
<presence
<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='403' type='auth'>
<forbidden
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
@ -87,7 +87,7 @@
</ol>
<p>If the server determines that the user is physically present in the vicinity of a client, it SHOULD return that information to the requesting entity, including the appropriate resource:</p>
<example caption='Server returns success'><![CDATA[
<presence
<presence
from='juliet@capulet.com/chamber'
to='romeo@montague.net/orchard'
id='poke1'>
@ -96,21 +96,21 @@
]]></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>
<example caption='Server returns request timeout error'><![CDATA[
<presence
<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='408' type='wait'>
<remote-server-timeout
<remote-server-timeout
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></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>
<example caption='Server returns gone error'><![CDATA[
<presence
<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
@ -119,7 +119,7 @@
<error code='302' type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Please accept our condolences: the user you are
Please accept our condolences: the user you are
trying to reach has died.
</text>
</error>
@ -146,7 +146,7 @@
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='501' type='cancel'>
<feature-not-implemented
<feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@ -223,8 +223,8 @@
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='method'
use='optional'
<xs:attribute name='method'
use='optional'
type='xs:NCName'/>
</xs:extension>
</xs:simpleContent>

226
xep-0133.xml
View File

@ -142,7 +142,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#add-user'/>
</iq>
@ -154,7 +154,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'
status='executing'>
@ -194,7 +194,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -229,7 +229,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'
status='completed'/>
@ -246,7 +246,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-user'/>
</iq>
@ -258,7 +258,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'
status='executing'>
@ -284,7 +284,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -304,7 +304,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'
status='completed'/>
@ -320,7 +320,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#disable-user'/>
</iq>
@ -332,7 +332,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'
status='executing'>
@ -358,7 +358,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -378,7 +378,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'
status='completed'/>
@ -394,7 +394,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#reenable-user'/>
</iq>
@ -406,7 +406,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'
status='executing'>
@ -432,7 +432,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -452,7 +452,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'
status='completed'/>
@ -460,7 +460,7 @@
]]></example>
</section2>
<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>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests to End a User&apos;s Session'><![CDATA[
<iq from='bard@shakespeare.lit/globe'
@ -468,7 +468,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#end-user-session'/>
</iq>
@ -480,7 +480,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'
status='executing'>
@ -506,7 +506,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -526,7 +526,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'
status='completed'/>
@ -542,7 +542,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-password'/>
</iq>
@ -554,7 +554,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'
status='executing'>
@ -580,7 +580,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -601,7 +601,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'
status='completed'>
@ -629,7 +629,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#change-user-password'/>
</iq>
@ -641,7 +641,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'
status='executing'>
@ -672,7 +672,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -695,7 +695,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'
status='completed'/>
@ -711,7 +711,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-roster'/>
</iq>
@ -723,7 +723,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'
status='executing'>
@ -749,7 +749,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -770,7 +770,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'
status='completed'>
@ -813,7 +813,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-lastlogin'/>
</iq>
@ -825,7 +825,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'
status='executing'>
@ -851,7 +851,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -872,7 +872,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'
status='completed'>
@ -900,7 +900,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#user-stats'/>
</iq>
@ -912,7 +912,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'
status='executing'>
@ -937,7 +937,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -957,7 +957,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'
status='completed'>
@ -996,7 +996,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-blacklist'/>
</iq>
@ -1008,7 +1008,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'
status='executing'>
@ -1035,7 +1035,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1057,7 +1057,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'
status='completed'/>
@ -1074,7 +1074,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-whitelist'/>
</iq>
@ -1086,7 +1086,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'
status='executing'>
@ -1116,7 +1116,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1139,7 +1139,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'
status='completed'/>
@ -1155,7 +1155,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-num'/>
</iq>
@ -1167,7 +1167,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-num'
sessionid='get-registered-users-num:20040408T0337Z'
status='completed'>
@ -1193,7 +1193,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-num'/>
</iq>
@ -1205,7 +1205,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-num'
sessionid='get-disabled-users-num:20040408T0337Z'
status='completed'>
@ -1231,7 +1231,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-online-users-num'/>
</iq>
@ -1243,7 +1243,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@ -1269,7 +1269,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-active-users-num'/>
</iq>
@ -1281,7 +1281,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@ -1307,7 +1307,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-idle-users-num'/>
</iq>
@ -1319,7 +1319,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@ -1345,7 +1345,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-list'/>
</iq>
@ -1361,7 +1361,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users-list:20040408T0337Z'
status='executing'>
@ -1395,7 +1395,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1415,7 +1415,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users:20040408T0337Z'
status='completed'>
@ -1463,7 +1463,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-list'/>
</iq>
@ -1479,7 +1479,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users-list:20040408T0337Z'
status='executing'>
@ -1513,7 +1513,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1533,7 +1533,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users:20040408T0337Z'
status='completed'>
@ -1562,7 +1562,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-online-users-list'/>
</iq>
@ -1578,7 +1578,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-list'
sessionid='get-online-users-list:20040408T0337Z'
status='executing'>
@ -1612,7 +1612,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='get-online-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1632,7 +1632,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-list'
sessionid='get-online-users:20040408T0337Z'
status='completed'>
@ -1671,7 +1671,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-active-users'/>
</iq>
@ -1687,7 +1687,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'
status='executing'>
@ -1721,7 +1721,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1741,7 +1741,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'
status='completed'>
@ -1773,7 +1773,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-idle-users'/>
</iq>
@ -1789,7 +1789,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-idle-users:20040408T0337Z'
status='executing'>
@ -1823,7 +1823,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-idle-users:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1843,7 +1843,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-active-users:20040408T0337Z'
status='completed'>
@ -1877,7 +1877,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#announce'/>
</iq>
@ -1889,7 +1889,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'
status='executing'>
@ -1917,7 +1917,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -1939,7 +1939,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'
status='completed'/>
@ -1947,7 +1947,7 @@
]]></example>
</section2>
<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);
<note>Typically, a "message of the day" is an announcement that is sent once to all users of a server or a service until and unless the message is deleted; it can be thought of as a "standing announcement" as opposed to the "one-time announcement" sent to all online users in the previous use cases. The announcement is sent immediately to users who are online when the message is set, or after the next session initiation for other users (e.g., on server login or chatroom join).</note>
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-motd".</p>
<p>A sample protocol flow for this use case is shown below.</p>
@ -1957,7 +1957,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#set-motd'/>
</iq>
@ -1969,7 +1969,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'
status='executing'>
@ -1996,7 +1996,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2020,7 +2020,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'
status='completed'/>
@ -2036,7 +2036,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-motd'/>
</iq>
@ -2048,7 +2048,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'
status='executing'>
@ -2080,7 +2080,7 @@
to='shakespeare.lit'
type='edit'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2104,7 +2104,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'
status='completed'/>
@ -2120,7 +2120,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-motd'/>
</iq>
@ -2132,7 +2132,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-motd'
sessionid='delete-motd:20040408T0337Z'
status='completed'/>
@ -2148,7 +2148,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#set-welcome'/>
</iq>
@ -2160,7 +2160,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'
status='executing'>
@ -2190,7 +2190,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2213,7 +2213,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'
status='completed'/>
@ -2229,7 +2229,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-welcome'/>
</iq>
@ -2241,7 +2241,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-welcome'
sessionid='delete-welcome:20040408T0337Z'
status='completed'/>
@ -2257,7 +2257,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-admin'/>
</iq>
@ -2269,7 +2269,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'
status='executing'>
@ -2298,7 +2298,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2319,7 +2319,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'
status='completed'/>
@ -2335,7 +2335,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#restart'/>
</iq>
@ -2347,7 +2347,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'
status='executing'>
@ -2381,7 +2381,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2405,7 +2405,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'
status='completed'/>
@ -2421,7 +2421,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#shutdown'/>
</iq>
@ -2433,7 +2433,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'
status='executing'>
@ -2467,7 +2467,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@ -2491,7 +2491,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'
status='completed'/>
@ -2527,7 +2527,7 @@
<td>The ad-hoc commands protocol is not supported.</td>
</tr>
</table>
<p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p>
<p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The ability to complete the administrative tasks specified herein MUST NOT be granted to users who lack service-level administrative privileges.</p>

2
xep-0134.xml
View File

@ -96,7 +96,7 @@
<p><em>Background</em></p>
<p>The core strength of Jabber technologies is the streaming of relatively small XML fragments between presence-aware network endpoints. As is usually the case, our greatest strength is also our greatest weakness. Thus XMPP is not optimized for binary data, large XML files, multimedia streaming, or other such applications.</p>
<p><em>Meaning</em></p>
<p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band
<p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band
<note>There are no hard-and-fast rules regarding a reasonable upper limit on the average XML stanza. (Note the use of both 'reasonable' and 'average' in that sentence.) In reality, there is a continuum of stanza sizes, and different sizes may be appropriate for different types of XMPP applications and deployments. While sending 2 gigabyte or 2 megabyte stanzas is wrong in the current context of Jabber technologies, we cannot legitimately say that a 2 kilobyte, 20 kilobyte, or even 200 kilobyte stanza is unreasonable. Is the stanza sent over an open network with current server implementations, or over a closed network with specially tuned servers and clients? Does the application generate one such stanza every second, every minute, every hour? Considerations of this kind help us determine if the use of XMPP is "reasonable" in some sense. However, when protocol extensions are defined in XMPP Extension Protocols, the XMPP Council will require clear explanation of design choices and reasonable stanza size limits if the extension will generally require what might be considered larger than normal stanzas.</note>
is probably not a good idea, and applications that would depend on such behavior are better designed to communicate their data out of band.</p>
<p><em>Examples</em></p>

80
xep-0135.xml
View File

@ -31,7 +31,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Existing Jabber protocols provide a strong foundation for the controlled, permissions-based sharing of files between Jabber entities, e.g., to enable shared workspaces among ad-hoc workgroups and the attachment of files to &xep0045; rooms.</p>
<p>This document defines several additional building blocks (a simple request protocol along with well-known service discovery nodes) that tie together existing protocols to enable the sharing of files between Jabber entities.</p>
<p>This document defines several additional building blocks (a simple request protocol along with well-known service discovery nodes) that tie together existing protocols to enable the sharing of files between Jabber entities.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ol>
@ -83,7 +83,7 @@
id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
<item jid='darkcave@macbeth.shakespeare.lit'
<item jid='darkcave@macbeth.shakespeare.lit'
node='files'
name='The files attached to this room'/>
...
@ -127,7 +127,7 @@
id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
<item jid='romeo@files.shakespeare.lit'
<item jid='romeo@files.shakespeare.lit'
node='files'
name='Romeo&apos;s Files'/>
...
@ -142,7 +142,7 @@
<example caption='Requesting the File List'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'/>
@ -151,7 +151,7 @@
<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[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
@ -161,10 +161,10 @@
<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[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir'/>
@ -182,7 +182,7 @@
<example caption='Requesting Further Information (1)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir'/>
@ -191,10 +191,10 @@
<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[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir'>
<identity category='filesys' type='directory'/>
</query>
@ -204,7 +204,7 @@
<example caption='Requesting Further Information (2)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/>
@ -213,10 +213,10 @@
<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[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'>
<identity category='filesys' type='file' name='file1'/>
</query>
@ -227,7 +227,7 @@
<example caption='Requesting Further Items (1)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir'/>
@ -236,10 +236,10 @@
<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[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir/anotherdir'/>
@ -253,7 +253,7 @@
<example caption='Requesting Further Information (3)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir'/>
@ -261,10 +261,10 @@
]]></example>
<example caption='Returning Further Information (3)'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir'>
<identity category='filesys' type='directory'/>
</query>
@ -273,7 +273,7 @@
<example caption='Requesting Further Information (4)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='info4'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherfile'/>
@ -281,10 +281,10 @@
]]></example>
<example caption='Returning Further Information (4)'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info4'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherfile'>
<identity category='filesys' type='file' name='file2'/>
</query>
@ -293,7 +293,7 @@
<example caption='Requesting Further Items (2)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='items2'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir/anotherdir'/>
@ -301,10 +301,10 @@
]]></example>
<example caption='Returning Further Items (2)'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='items2'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir/anotherdir'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir/anotherdir/yetanotherfile'
@ -315,7 +315,7 @@
<example caption='Requesting Further Information (5)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='info5'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir/yetanotherfile'/>
@ -323,10 +323,10 @@
]]></example>
<example caption='Returning Further Information (5)'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info5'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir/yetanotherfile'>
<identity category='filesys' type='file' name='file3'/>
</query>
@ -348,7 +348,7 @@ share
<example caption='Requesting the File List'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'/>
@ -356,10 +356,10 @@ share
]]></example>
<example caption='Returning the File List'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir'/>
@ -397,7 +397,7 @@ share
<example caption='Requesting File Information'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='file1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/>
@ -405,10 +405,10 @@ share
]]></example>
<example caption='Returning Detailed File Information'><![CDATA[
<iq type='result'
from='darkcave@macbeth.shakespeare.lit'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'>
<identity category='filesys' type='file' name='file1'/>
<x xmlns='jabber:x:data' type='result'>
@ -442,7 +442,7 @@ share
<example caption='Retrieving a File'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
to='darkcave@macbeth.shakespeare.lit'
id='retrieve1'>
<retrieve xmlns='http://jabber.org/protocol/files'
node='files/somefile'/>
@ -455,11 +455,11 @@ share
]]></example>
<example caption='Offering Entity Initiates File Transfer'>
<![CDATA[
<iq type='set'
from='darkcave@macbeth.shakespeare.lit'
id='offer1'
<iq type='set'
from='darkcave@macbeth.shakespeare.lit'
id='offer1'
to='hag66@shakespeare.lit/pda'>
<si xmlns='http://jabber.org/protocol/si'
<si xmlns='http://jabber.org/protocol/si'
id='file1'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -537,7 +537,7 @@ share
targetNamespace='http://jabber.org/protocol/files'
xmlns='http://jabber.org/protocol/files'
elementFormDefault='qualified'>
<xs:element name='retrieve'>
<xs:complexType>
<xs:simpleContent>

8
xep-0136.xml
View File

@ -203,7 +203,7 @@
<p>In order to capture a complete set of preferences, when the server returns the user's preferences to the client the &lt;pref/&gt; element:</p>
<ul>
<li>MUST include an &lt;auto/&gt; element that specifies whether automatic archiving is on or off.</li>
<li>MUST include a &lt;default/&gt; element that specifies the user's default settings for OTR Mode and Save Mode.</li>
<li>MUST include a &lt;default/&gt; element that specifies the user's default settings for OTR Mode and Save Mode.</li>
<li>MAY include one or more &lt;item/&gt; elements that specify preferences related to particular contacts.</li>
<li>MAY include one or more &lt;session/&gt; elements that specifies whether automatic archiving is on or off for a given chat session.</li>
<li>MUST include at least three &lt;method/&gt; elements, differentiated by the value of the 'type' attribute (i.e., at least one &lt;method/&gt; element each for "auto", "local", and "manual").</li>
@ -488,7 +488,7 @@
]]></example>
</section2>
<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>
<example caption='Client Sets Method Preferences'><![CDATA[
<iq type='set' id='pref5'>
<pref xmlns='urn:xmpp:archive'>
@ -1176,7 +1176,7 @@
<example caption='Client Service Discovery request'>
<![CDATA[
<iq from='romeo@montague.net/orchard'
id='disco1'
id='disco1'
to='montague.net'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -1186,7 +1186,7 @@
<example caption='Server Service Discovery response'>
<![CDATA[
<iq from='montague.net'
id='disco1'
id='disco1'
to='romeo@montague.net/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>

10
xep-0139.xml
View File

@ -45,16 +45,16 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Because security is a core value within the Jabber community, it is appropriate for the XMPP Standards Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Special Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.</p>
</section1>
</section1>
<section1 topic='Scope and Role' anchor='scope'>
<p>The role of the Security SIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security SIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SSIG; and the Jabber Council respectively.</p>
</section1>
</section1>
<section1 topic='Membership' anchor='membership'>
<p>The Security SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Security SIG discussions shall be conducted in open forums, including a dedicated mailing list at &lt;security-jig@jabber.org&gt;. The process for moderating such discussions shall be decided by the members of the Security SIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.</p>
</section1>
</section1>
<section1 topic='Lifetime' anchor='lifetime'>
<p>The Security SIG shall be a standing SIG, and shall exist as long as the Jabber Council deems it useful.</p>
</section1>
</section1>
<section1 topic='Deliverables' anchor='deliverables'>
<p>The Security SIG shall produce at least the following deliverables:</p>
<ol>
@ -78,7 +78,7 @@
<li>Existing approaches for addressing the threat (e.g., as documented in a XEP)</li>
<li>The gap between the identified threat and existing responses</li>
<li>Potential approaches to addressing the threat or closing the gap, including implementation issues associated with each approach (since security measures that cannot or will not be implemented are useless)</li>
<li>Current recommended approach (which may be "do nothing at this time")</li>
<li>Current recommended approach (which may be "do nothing at this time")</li>
</ol>
<p>The template will not fully define the foregoing information, but instead specify what information must be defined for each threat when completing the analysis described in Step 3.</p>
</li>

6
xep-0140.xml
View File

@ -116,7 +116,7 @@
<publish node='groups/Marketing/Europe'>
<item id='alice@example.com'>
<x xmlns='jabber:x:roster'
jid='alice@example.com'
jid='alice@example.com'
name='Alice Rosenbaum'>
<group>Marketing/Europe</group>
</x>
@ -134,7 +134,7 @@
<items node='groups/Marketing/Europe'>
<item id='alice@example.com'>
<x xmlns='jabber:x:roster'
jid='alice@example.com'
jid='alice@example.com'
name='Alice Rosenbaum'>
<group>Marketing/Europe</group>
</x>
@ -210,7 +210,7 @@
<p>An administrator may wish to define a hierarchy of shared groups (e.g., "Marketing/Europe" and "Marketing/North America"). This can be done using collection nodes as defined in Section 9 of XEP-0060. The receiving application MAY use &xep0083; to define the roster group names.</p>
</section2>
<section2 topic='Exchanging Presence' anchor='impl-pres'>
<p>Presence is exchanged via the normal mechanisms defined in <strong>XMPP IM</strong>.</p>
<p>Presence is exchanged via the normal mechanisms defined in <strong>XMPP IM</strong>.</p>
</section2>
<section2 topic='Sending Messages' anchor='impl-msg'>
<p>In order to send a message to all members of a shared group, a group member's sending application (usually an end-user client) SHOULD either send multiple messages or use &xep0033;.</p>

42
xep-0141.xml
View File

@ -68,7 +68,7 @@
<x xmlns='jabber:x:data' type='form'>
<title>XSF Application</title>
<instructions>Please fill out this form</instructions>
<field var='name.first' type='text-single' label='First Name'>
<required/>
</field>
@ -81,14 +81,14 @@
<field var='jid' type='jid-single' label='Jabber JID'>
<required/>
</field>
<field var='background' type='text-multi' label='Background Information'>
</field>
<field var='future' type='text-multi' label='Jabber Plans for the Next Six Months'>
</field>
<field var='reasoning' type='text-multi' label='Reasons for Joining'>
</field>
<field var='activity.mailing-lists' type='text-multi' label='Recent Mailing List Activity'>
</field>
<field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'>
@ -105,8 +105,8 @@
<page xmlns='http://jabber.org/protocol/xdata-layout' label='Personal Information'>
<text>This is page one of three.</text>
<text>
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<fieldref var='name.first'/>
@ -118,7 +118,7 @@
<page xmlns='http://jabber.org/protocol/xdata-layout' label='Community Activity'>
<text>This is page two of three.</text>
<text>
We use this page to gather information about any XEPs you&apos;ve worked on,
We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@ -129,7 +129,7 @@
<text>This is page three of three.</text>
<text>You're almost done!</text>
<text>
This is where you describe your future plans and why you think you
This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
@ -170,8 +170,8 @@
<page xmlns='http://jabber.org/protocol/xdata-layout'>
<section label='Personal Information'>
<text>
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<fieldref var='name.first'/>
@ -182,7 +182,7 @@
</section>
<section label='Community Activity'>
<text>
We use this page to gather information about any XEPs you&apos;ve worked on,
We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@ -192,7 +192,7 @@
<section label='Plans and Reasoning'>
<text>You're almost done!</text>
<text>
This is where you describe your future plans and why you think you
This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
@ -228,12 +228,12 @@
<example caption='Sections of fields (nested)'><![CDATA[
<x xmlns='jabber:x:data' type='form'>
...
<page xmlns='http://jabber.org/protocol/xdata-layout'>
<section label='Personal Information'>
<text>
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<section label='Name'>
@ -250,7 +250,7 @@
</section>
<section label='Community Activity'>
<text>
We use this page to gather information about any XEPs you&apos;ve worked on,
We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@ -259,18 +259,18 @@
</section>
<section label='Plans and Reasoning'>
<text>
This is where you describe your future plans and why you think you
This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
<fieldref var='reasoning'/>
</section>
</page>
...
</x>
]]></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 topic="Including Tables" anchor='tables'>
<p>Data forms tables (the &lt;reported/&gt; and &lt;item/&gt; elements) can also be included in the layout, using the &lt;reportedref/&gt; element. This element MAY be included anywhere that the &lt;fieldref/&gt; element is allowed, but MUST NOT appear more than once.</p>
@ -358,7 +358,7 @@
<xs:attribute name='label' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='section'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
@ -380,11 +380,11 @@
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='reportedref' type='empty'/>
<xs:element name='text' type='xs:string'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>

8
xep-0142.xml
View File

@ -484,7 +484,7 @@ S: to='user@example.net/home'>
S: <x xmlns='http://jabber.org/protocol/muc#user'>
S: <invite from='support@workgroup.example.com'>
S: <reason>
S: You have been invited to chat with a support@workgroup.example.com
S: You have been invited to chat with a support@workgroup.example.com
agent.
S: </reason>
S: </invite>
@ -700,14 +700,14 @@ Agent Service
<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>
<example caption='Request Element'><![CDATA[
U: <iq to='support@workgroup.example.com' from='alice@example.com/work'
U: <iq to='support@workgroup.example.com' from='alice@example.com/work'
U: id='id1' type='get'>
U: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'/>
U: </iq>
]]></example>
<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[
S: <iq to='alice@example.com/work' from='support@workgroup.example.com'
S: <iq to='alice@example.com/work' from='support@workgroup.example.com'
S: id='id1' type='result'>
S: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'>
S: <agent jid='bob@example.com' />
@ -1043,7 +1043,7 @@ S: </iq>
</xs:documentation>
</xs:annotation>
<xs:import
<xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>

12
xep-0143.xml
View File

@ -180,7 +180,7 @@
</ul>
<p>We repeat: include lots of protocol examples. Examples help not only implementers but also those who will review your proposal in the Standards SIG and XMPP Council. You get extra credit with the XMPP Extensions Editor team if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:</p>
<example caption='An Example from Shakespeare'><![CDATA[
<message
<message
from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
type='chat'>
@ -234,16 +234,16 @@
<p>Examples are the major source of right-scrolling in our HTML output files. Right-scrolling is evil. Therefore, adjust your example layouts accordingly (line widths should be no more than 110 characters or so).</p>
<p>Example:</p>
<code><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='config1'
to='crone1@shakespeare.lit/desktop'
<iq from='darkcave@macbeth.shakespeare.lit'
id='config1'
to='crone1@shakespeare.lit/desktop'
type='result'>
<query xmlns='http://jabber.org/protocol/muc#roomconfig'>
<x xmlns='jabber:x:data' type='form'>
<title>Configuration for "darkcave" Room</title>
<instructions>
Please complete this form to make changes to the configuration
of your room; to add room owners and administrators, use the
Please complete this form to make changes to the configuration
of your room; to add room owners and administrators, use the
appropriate room commands rather than this form.
</instructions>
<field type='hidden' var='FORM_TYPE'>

22
xep-0144.xml
View File

@ -107,7 +107,7 @@
<example caption='Suggesting Addition'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
<body>Some visitors, m'lord!</body>
<x xmlns='http://jabber.org/protocol/rosterx'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<item action='add'
jid='rosencrantz@denmark.lit'
name='Rosencrantz'>
@ -134,16 +134,16 @@
<p>In order to programatically suggest that the receiving entity should delete one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more &lt;item/&gt; child elements, each of which MUST possess an 'action' attribute whose value is "delete", MUST possess a 'jid' attribute that specifies the JabberID of the item to be deleted, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more &lt;group/&gt; elements specifying roster groups for the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:</p>
<example caption='Suggesting Deletion'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<item action='delete'
jid='rosencrantz@denmark'
name='Rosencrantz'>
<group>Visitors</group>
</item>
<item action='delete'
jid='guildenstern@denmark'
name='Guildenstern'>
<group>Visitors</group>
name='Rosencrantz'>
<group>Visitors</group>
</item>
<item action='delete'
jid='guildenstern@denmark'
name='Guildenstern'>
<group>Visitors</group>
</item>
</x>
</message>
@ -160,7 +160,7 @@
<p>In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more &lt;item/&gt; child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be modified, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more &lt;group/&gt; elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:</p>
<example caption='Suggesting Modification'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<x xmlns='http://jabber.org/protocol/rosterx'>
<item action='modify'
jid='rosencrantz@denmark.lit'
name='Rosencrantz'>
@ -244,7 +244,7 @@
<p>There is a third category of entities that might initiate roster item exchanges, which we label a "group service" and identify by a <cite>Service Discovery</cite> category of "directory" and type of "group". A group service enables an administrator to centrally define and administer roster groups so that they can be shared among a user population in an organized fashion. Such a service could prove useful in enterprise environments
<note>For example, when Alice is hired by the marketing department of Big Company Enterprises, it makes sense for her to automatically have the other members of the marketing department in her roster the first time she logs in, and for the rest of the marketing department to have Alice in their rosters as soon as her account has been set up. Similarly, when Bob in logistics gets fired, it makes sense for him to disappear from the rosters of everyone else in the logistics department.</note>
and other settings where it is beneficial to synchronize rosters across individuals (e.g., schools, social networking applications, consumer IM services, and anywhere else that it is important to build and manage small communities of users).</p>
<p>In some contexts, an IM server could function as a group service (e.g., if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (e.g., in a larger or more heterogeneous environment with users on multiple servers). In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via &xep0077; or out of band, e.g., via the web) or be otherwise provisioned to use the service (e.g., by a system administrator) before accepting roster item suggestions from the service.</p>
<p>In some contexts, an IM server could function as a group service (e.g., if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (e.g., in a larger or more heterogeneous environment with users on multiple servers). In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via &xep0077; or out of band, e.g., via the web) or be otherwise provisioned to use the service (e.g., by a system administrator) before accepting roster item suggestions from the service.</p>
<p>If the user has registered with a group service or been otherwise provisioned to use a group service, the receiving application SHOULD process roster item suggestions received from the service. Such processing MAY occur automatically (i.e., without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the service. Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (e.g., once per session in which the service sends roster item suggestions to the user).</p>
</section2>
</section1>

2
xep-0145.xml
View File

@ -64,7 +64,7 @@
</section1>
<section1 topic='The storage:rosternotes Namespace' anchor='ns_storage_notes'>
<p>Annotations are stored using server-side private XML storage (the 'jabber:iq:private' namespace). A storage element marked by the storage:rosternotes namespace contains a collection of one or more &lt;note/&gt; elements, each representing a note about a given entity. For any given JID there MUST NOT be more than one note.</p>
<p>The 'jid' attribute of the &lt;note/&gt; element SHOULD be used without a resource. Along with the annotation a client MAY choose to store creation time ('cdate') and modification time ('mdate') as attributes to the &lt;note/&gt; element containing the note; these attributes MUST conform to the DateTime profile specified in &xep0082; and the timezone SHOULD be UTC.</p>

182
xep-0146.xml
View File

@ -33,7 +33,7 @@
<version>0.3</version>
<date>2006-01-25</date>
<initials>rt</initials>
<remark>Using XEP-0033 (Extended Stanza Addressing) for Forwarding
<remark>Using XEP-0033 (Extended Stanza Addressing) for Forwarding
use case.</remark>
</revision>
<revision>
@ -52,14 +52,14 @@
<section1 topic='Introduction' anchor='intro'>
<p>
When one has multiple clients at different locations logged in
simultaneously, it is often desirable to control these clients from
When one has multiple clients at different locations logged in
simultaneously, it is often desirable to control these clients from
the client you are currently using. There are a number of common tasks
one might want to perform remotely on clients: change the status of the
client, forward all received unread messages to this client, and so on.
Therefore, it makes sense to define a protocol for performing these tasks.
</p>
<p>
This document describes a protocol to perform a set of common tasks on a
remote client, by specifying a profile of &xep0050;.
@ -70,7 +70,7 @@
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p>
<ul>
<li>Enable users to perform a set of common tasks on a remote
<li>Enable users to perform a set of common tasks on a remote
client.</li>
<li>Re-use existing XMPP and Jabber protocols wherever possible.</li>
</ul>
@ -78,7 +78,7 @@
<section1 topic='Discovery' anchor='disco'>
<p>A client MUST advertise any remote controlling commands it supports via
<p>A client MUST advertise any remote controlling commands it supports via
&xep0030; (as described in <strong>XEP-0050: Ad-Hoc Commands</strong>).
&xep0115; can be used to query capability of remote controlling commands
in a client.
@ -107,8 +107,8 @@
<section2 topic='Change Status' anchor='set-status'>
<p>It is common to forget changing the status of a resource when leaving the
client for a longer period. When realizing this while at another location, it
might be desirable to change the status from there, to avoid contacts
client for a longer period. When realizing this while at another location, it
might be desirable to change the status from there, to avoid contacts
thinking that resource is attended and sending it messages.</p>
<example caption='Local Client Requests to Set the Status of a Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
@ -116,19 +116,19 @@
type='set'
id='set-status-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#set-status'/>
</iq>
]]></example>
<p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service
<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='Remote Client Replies with a Form to Set its Status'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='set-status-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -141,40 +141,40 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
<field label='Status'
type='list-single'
<field label='Status'
type='list-single'
var='status'>
<required/>
<value>online</value>
<option label='Chat'>
<option label='Chat'>
<value>chat</value>
</option>
<option label='Online'>
<option label='Online'>
<value>online</value>
</option>
<option label='Away'>
<option label='Away'>
<value>away</value>
</option>
<option label='Extended Away'>
<option label='Extended Away'>
<value>xa</value>
</option>
<option label='Do Not Disturb'>
<option label='Do Not Disturb'>
<value>dnd</value>
</option>
<option label='Invisible'>
<option label='Invisible'>
<value>invisible</value>
</option>
<option label='Offline'>
<option label='Offline'>
<value>offline</value>
</option>
</field>
<field label='Priority'
type='text-single'
var='status-priority'>
<value>5</value>
<value>5</value>
</field>
<field label='Message'
type='text-multi'
<field label='Message'
type='text-multi'
var='status-message'/>
</x>
</command>
@ -186,7 +186,7 @@
type='set'
id='set-status-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-status'
sessionid='set-status:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@ -209,9 +209,9 @@
<p>If the 'status-priority' variable is omitted, the client SHOULD NOT
change the priority of the client</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='set-status-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -220,7 +220,7 @@
status='completed'/>
</iq>
]]></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>
</section2>
@ -254,7 +254,7 @@
type='set'
id='forward-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z'/>
@ -267,7 +267,7 @@
the command was completed.
</p>
<example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
<message from='juliet@example.com/balcony'
<message from='juliet@example.com/balcony'
to='juliet@example.com/chamber'>
<subject>Just saying hi</subject>
<body>Hello Juliet!</body>
@ -279,9 +279,9 @@
stamp='2002-09-10T23:41:07Z'/>
</message>]]></example>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='forward-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -310,7 +310,7 @@
type='set'
id='set-options-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#set-options'/>
</iq>]]></example>
@ -340,23 +340,23 @@
var='sounds'>
<value>1</value>
</field>
<field label='Automatically Go Offline when Idle'
type='boolean'
<field label='Automatically Go Offline when Idle'
type='boolean'
var='auto-offline'>
<value>0</value>
</field>
<field label='Automatically Open New Messages'
type='boolean'
<field label='Automatically Open New Messages'
type='boolean'
var='auto-msg'>
<value>0</value>
</field>
<field label='Automatically Accept File Transfers'
type='boolean'
<field label='Automatically Accept File Transfers'
type='boolean'
var='auto-files'>
<value>0</value>
</field>
<field label='Automatically Authorize Contacts'
type='boolean'
<field label='Automatically Authorize Contacts'
type='boolean'
var='auto-auth'>
<value>0</value>
</field>
@ -369,7 +369,7 @@
type='set'
id='set-options-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@ -425,7 +425,7 @@
type='set'
id='accept-files-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#accept-files'/>
</iq>]]></example>
@ -450,17 +450,17 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
<field label='Files'
type='list-multi'
<field label='Files'
type='list-multi'
var='files'>
<required/>
<option label='ballad.ogg (romeo@example.com)'>
<option label='ballad.ogg (romeo@example.com)'>
<value>romeo@example.com/orchard:1</value>
</option>
<option label='picture.jpg (romeo@example.com)'>
<option label='picture.jpg (romeo@example.com)'>
<value>romeo@example.com/orchard:2</value>
</option>
<option label='challenge.txt (mercutio@example.com)'>
<option label='challenge.txt (mercutio@example.com)'>
<value>mercutio@example.com/orchard:1</value>
</option>
</field>
@ -473,7 +473,7 @@
type='set'
id='accept-files-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#accept-files'
sessionid='accept-files:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@ -491,9 +491,9 @@
local client of completion.
</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='accept-files-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -512,15 +512,15 @@
type='set'
id='leave-groupchats-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#leave-groupchats'/>
</iq>
]]></example>
<example caption='Remote Client Replies with a Form with a List of Groupchats it is currently in'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='leave-groupchats-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -533,17 +533,17 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
<field label='Groupchats'
type='list-multi'
<field label='Groupchats'
type='list-multi'
var='groupchats'>
<required/>
<option label='juliet on jdev@conference.jabber.org'>
<option label='juliet on jdev@conference.jabber.org'>
<value>jdev@conference.jabber.org/juliet</value>
</option>
<option label='juliette on jdev@conference.jabber.org'>
<option label='juliette on jdev@conference.jabber.org'>
<value>jdev@conference.jabber.org/juliette</value>
</option>
<option label='juliet on girlsonly@jabber.com'>
<option label='juliet on girlsonly@jabber.com'>
<value>girlsonly@jabber.com/juliet</value>
</option>
</field>
@ -557,7 +557,7 @@
type='set'
id='leave-groupchats-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
<command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#leave-groupchats'
sessionid='leave-groupchats:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@ -575,9 +575,9 @@
<p>The remote client leaves the requested groupchats, and informs the
local client of completion.</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='leave-groupchats-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@ -589,8 +589,8 @@
</section2>
</section1>
<section1 topic='Error Handling' anchor='errors'>
<section1 topic='Error Handling' anchor='errors'>
<p>Several error conditions are possible when an entity sends a command
request to the service, as defined in the following table. If one of these
errors occurs, the service MUST return an error stanza to the requesting
@ -613,7 +613,7 @@
</tr>
<tr>
<td>&forbidden;</td>
<td>The requesting entity does not have sufficient privileges to
<td>The requesting entity does not have sufficient privileges to
perform the command</td>
</tr>
<tr>
@ -621,32 +621,32 @@
<td>The ad-hoc commands protocol is not supported</td>
</tr>
</table>
<p>For the syntax of these errors, see &xep0086;. Naturally, other errors
may be returned as well.</p>
</section1>
<section1 topic='Implementation Notes' anchor='implementation'>
<section1 topic='Implementation Notes' anchor='implementation'>
<p>Implementations of this protocol MAY add or remove fields to forms as
they see fit. For example, when setting the status of a remote client that
supports multiple accounts, the client may choose to add a boolean field
supports multiple accounts, the client may choose to add a boolean field
to allow the user to specify whether the status change should be applied
globally or only to the receiving account.</p>
<p> Implementations MAY also introduce extra forms for commands. For example,
when forwarding unread messages, a client could return a form containing a
list
when forwarding unread messages, a client could return a form containing a
list
of short descriptions of unread messages, allowing the user to select the
messages he wants to forward.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The ability to complete the tasks specified herein MUST NOT be granted
to users who lack privileges to control a client. A sensible
access policy is to only allow remote controlling by other
to users who lack privileges to control a client. A sensible
access policy is to only allow remote controlling by other
resources of the same account used by the client. If other accounts
are to be able to remote control the client, the client needs more
are to be able to remote control the client, the client needs more
complex access right management.</p>
</section1>
@ -657,7 +657,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
<p>The XMPP Registrar includes 'http://jabber.org/protocol/rc' in its registry
of protocol namespaces (see &NAMESPACES;).</p>
@ -665,8 +665,8 @@
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&xep0068; defines a process for standardizing the fields used within
Data Forms scoped by a particular namespace (see also &FORMTYPES;).
The reserved fields for the 'http://jabber.org/protocol/rc' namespace
Data Forms scoped by a particular namespace (see also &FORMTYPES;).
The reserved fields for the 'http://jabber.org/protocol/rc' namespace
are specified below.</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
@ -697,25 +697,25 @@
<field var='status'
type='list-single'
label='A presence or availability status'>
<option label='Chat'>
<option label='Chat'>
<value>chat</value>
</option>
<option label='Online'>
<option label='Online'>
<value>online</value>
</option>
<option label='Away'>
<option label='Away'>
<value>away</value>
</option>
<option label='Extended Away'>
<option label='Extended Away'>
<value>xa</value>
</option>
<option label='Do Not Disturb'>
<option label='Do Not Disturb'>
<value>dnd</value>
</option>
<option label='Invisible'>
<option label='Invisible'>
<value>invisible</value>
</option>
<option label='Offline'>
<option label='Offline'>
<value>offline</value>
</option>
</field>

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