Browse Source

Remove all trailing whitespace from every XEP.

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

40
xep-0001.xml

@ -211,7 +211,7 @@ @@ -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 @@ -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 @@ -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. @@ -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. @@ -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. @@ -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. @@ -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. @@ -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. @@ -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. @@ -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. @@ -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

@ -317,7 +317,7 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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

@ -70,7 +70,7 @@ @@ -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

@ -5,7 +5,7 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -255,7 +255,7 @@
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:complexType>
</xs:element>
<xs:complexType name="ParamType">
@ -286,7 +286,7 @@ @@ -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 @@ @@ -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

@ -81,7 +81,7 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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

@ -122,12 +122,12 @@ @@ -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 @@ @@ -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 @@ @@ -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 ...> @@ -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 ...> @@ -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. @@ -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. @@ -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. @@ -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

@ -119,7 +119,7 @@ @@ -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

@ -52,7 +52,7 @@ @@ -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

@ -48,14 +48,14 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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

@ -7,7 +7,7 @@ @@ -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: @@ -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 @@ -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: @@ -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 @@ -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' @@ -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: @@ -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' @@ -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' @@ -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. @@ -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> @@ -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' @@ -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). @@ -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 @@ -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 @@ -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. @@ -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' @@ -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, @@ -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. @@ -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. @@ -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: @@ -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> @@ -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: @@ -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' @@ -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' @@ -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' @@ -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. @@ -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. @@ -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 @@ -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> @@ -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'? @@ -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

@ -293,7 +293,7 @@ @@ -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 @@ -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 @@ -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

@ -89,7 +89,7 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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

@ -71,11 +71,11 @@ @@ -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 @@ @@ -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

@ -410,7 +410,7 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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 @@ @@ -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'