Browse Source

Remove all trailing whitespace from every XEP.

sed -i 's/\s\+$//' xep-*.xml
master
Emmanuel Gil Peyrot 2 years ago
parent
commit
3c5f20a4ca
100 changed files with 1757 additions and 1757 deletions
  1. 20
    20
      xep-0001.xml
  2. 8
    8
      xep-0004.xml
  3. 1
    1
      xep-0007.xml
  4. 29
    29
      xep-0009.xml
  5. 12
    12
      xep-0012.xml
  6. 16
    16
      xep-0013.xml
  7. 1
    1
      xep-0018.xml
  8. 1
    1
      xep-0019.xml
  9. 7
    7
      xep-0021.xml
  10. 48
    48
      xep-0024.xml
  11. 3
    3
      xep-0025.xml
  12. 8
    8
      xep-0026.xml
  13. 11
    11
      xep-0029.xml
  14. 13
    13
      xep-0030.xml
  15. 266
    266
      xep-0031.xml
  16. 7
    7
      xep-0032.xml
  17. 16
    16
      xep-0033.xml
  18. 2
    2
      xep-0034.xml
  19. 1
    1
      xep-0035.xml
  20. 1
    1
      xep-0036.xml
  21. 40
    40
      xep-0037.xml
  22. 16
    16
      xep-0040.xml
  23. 61
    61
      xep-0042.xml
  24. 166
    166
      xep-0043.xml
  25. 1
    1
      xep-0046.xml
  26. 5
    5
      xep-0047.xml
  27. 6
    6
      xep-0048.xml
  28. 1
    1
      xep-0049.xml
  29. 4
    4
      xep-0051.xml
  30. 13
    13
      xep-0052.xml
  31. 100
    100
      xep-0054.xml
  32. 5
    5
      xep-0056.xml
  33. 4
    4
      xep-0057.xml
  34. 1
    1
      xep-0058.xml
  35. 7
    7
      xep-0061.xml
  36. 5
    5
      xep-0063.xml
  37. 3
    3
      xep-0064.xml
  38. 6
    6
      xep-0065.xml
  39. 3
    3
      xep-0066.xml
  40. 5
    5
      xep-0067.xml
  41. 14
    14
      xep-0068.xml
  42. 22
    22
      xep-0070.xml
  43. 35
    35
      xep-0071.xml
  44. 41
    41
      xep-0072.xml
  45. 3
    3
      xep-0073.xml
  46. 8
    8
      xep-0074.xml
  47. 9
    9
      xep-0075.xml
  48. 5
    5
      xep-0076.xml
  49. 2
    2
      xep-0077.xml
  50. 6
    6
      xep-0078.xml
  51. 4
    4
      xep-0079.xml
  52. 8
    8
      xep-0080.xml
  53. 9
    9
      xep-0081.xml
  54. 3
    3
      xep-0084.xml
  55. 23
    23
      xep-0085.xml
  56. 1
    1
      xep-0086.xml
  57. 21
    21
      xep-0087.xml
  58. 3
    3
      xep-0088.xml
  59. 1
    1
      xep-0090.xml
  60. 1
    1
      xep-0091.xml
  61. 1
    1
      xep-0093.xml
  62. 6
    6
      xep-0095.xml
  63. 11
    11
      xep-0096.xml
  64. 2
    2
      xep-0097.xml
  65. 44
    44
      xep-0098.xml
  66. 61
    61
      xep-0099.xml
  67. 114
    114
      xep-0102.xml
  68. 1
    1
      xep-0103.xml
  69. 3
    3
      xep-0104.xml
  70. 8
    8
      xep-0105.xml
  71. 2
    2
      xep-0107.xml
  72. 5
    5
      xep-0108.xml
  73. 13
    13
      xep-0109.xml
  74. 18
    18
      xep-0111.xml
  75. 3
    3
      xep-0112.xml
  76. 22
    22
      xep-0113.xml
  77. 2
    2
      xep-0114.xml
  78. 14
    14
      xep-0115.xml
  79. 1
    1
      xep-0117.xml
  80. 2
    2
      xep-0119.xml
  81. 1
    1
      xep-0120.xml
  82. 22
    22
      xep-0122.xml
  83. 2
    2
      xep-0124.xml
  84. 19
    19
      xep-0127.xml
  85. 3
    3
      xep-0129.xml
  86. 11
    11
      xep-0130.xml
  87. 2
    2
      xep-0131.xml
  88. 13
    13
      xep-0132.xml
  89. 113
    113
      xep-0133.xml
  90. 1
    1
      xep-0134.xml
  91. 40
    40
      xep-0135.xml
  92. 4
    4
      xep-0136.xml
  93. 5
    5
      xep-0139.xml
  94. 3
    3
      xep-0140.xml
  95. 21
    21
      xep-0141.xml
  96. 4
    4
      xep-0142.xml
  97. 6
    6
      xep-0143.xml
  98. 11
    11
      xep-0144.xml
  99. 1
    1
      xep-0145.xml
  100. 0
    0
      xep-0146.xml

+ 20
- 20
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>

+ 8
- 8
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'/>

+ 1
- 1
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>

+ 29
- 29
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>

+ 12
- 12
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'>

+ 16
- 16
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>

+ 1
- 1
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>

+ 1
- 1
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>

+ 7
- 7
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>


+ 48
- 48
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>


+ 3
- 3
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)">


+ 8
- 8
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>


+ 11
- 11
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>

+ 13
- 13
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>

+ 266
- 266
xep-0031.xml
File diff suppressed because it is too large
View File


+ 7
- 7
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>

+ 16
- 16
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

+ 2
- 2
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>

+ 1
- 1
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>


+ 1
- 1
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>

+ 40
- 40
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

+ 16
- 16
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"

+ 61
- 61
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'