Browse Source

Remove all trailing whitespace from every XEP.

sed -i 's/\s\+$//' xep-*.xml
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 @@
211 211
   <ol start='1'>
212 212
     <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>
213 213
     <li>To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
214
-    <li>To ensure interoperability among the disparate technologies used on XMPP networks.</li> 
214
+    <li>To ensure interoperability among the disparate technologies used on XMPP networks.</li>
215 215
     <li>To guarantee that any person or entity can implement the protocols without encumbrance.</li>
216 216
     <li>To work in an fair, open, objective manner.</li>
217 217
   </ol>
@@ -350,8 +350,8 @@ Experimental ----> Proposed ----> Active
350 350
                                              |
351 351
                                              +--> Obsolete
352 352
     </code>
353
-    <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> 
354
-    <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> 
353
+    <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>
354
+    <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>
355 355
     <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>
356 356
   </section2>
357 357
 </section1>
@@ -370,7 +370,7 @@ Experimental ----> Proposed ----> Active
370 370
   </section2>
371 371
   <section2 topic='Final' anchor='states-Final'>
372 372
     <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>
373
-    <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> 
373
+    <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>
374 374
   </section2>
375 375
   <section2 topic='Active' anchor='states-Active'>
376 376
     <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 453
     <xs:annotation>
454 454
       <xs:documentation>
455 455
 
456
-        This schema defines the document format for XMPP Extension 
456
+        This schema defines the document format for XMPP Extension
457 457
         Protocols (XEPs). For further information about XEPs, visit:
458 458
 
459
-           http://www.xmpp.org/extensions/ 
459
+           http://www.xmpp.org/extensions/
460 460
 
461 461
         The canonical URL for this schema is:
462 462
 
@@ -481,20 +481,20 @@ THE SOFTWARE.
481 481
         <xs:element name='number' type='xs:byte'/>
482 482
         <xs:element ref='status'/>
483 483
         <xs:element name='lastcall' minOccurs='0' type='xs:string'/>
484
-        <xs:element name='interim' minOccurs='0' type='empty'/> 
485
-        <xs:element ref='type'/> 
484
+        <xs:element name='interim' minOccurs='0' type='empty'/>
485
+        <xs:element ref='type'/>
486 486
         <xs:element name='sig' type='xs:string'/>
487 487
         <xs:element name='approver' type='xs:string'/>
488 488
         <xs:element ref='dependencies'/>
489 489
         <xs:element ref='supersedes'/>
490 490
         <xs:element ref='supersededby'/>
491 491
         <xs:element name='shortname' type='xs:NCName'/>
492
-        <xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/> 
493
-        <xs:element name='registry' minOccurs='0' type='empty'/> 
492
+        <xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
493
+        <xs:element name='registry' minOccurs='0' type='empty'/>
494 494
         <xs:element name='discuss' minOccurs='0' type='xs:string'/>
495 495
         <xs:element name='expires' minOccurs='0' type='xs:string'/>
496
-        <xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/> 
497
-        <xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/> 
496
+        <xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
497
+        <xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
498 498
       </xs:sequence>
499 499
     </xs:complexType>
500 500
   </xs:element>
@@ -744,7 +744,7 @@ THE SOFTWARE.
744 744
     <xs:complexType>
745 745
       <xs:simpleContent>
746 746
         <xs:extension base='empty'>
747
-          <xs:attribute name='source' use='required'/> 
747
+          <xs:attribute name='source' use='required'/>
748 748
         </xs:extension>
749 749
       </xs:simpleContent>
750 750
     </xs:complexType>
@@ -754,7 +754,7 @@ THE SOFTWARE.
754 754
     <xs:complexType>
755 755
       <xs:simpleContent>
756 756
         <xs:extension base='xs:string'>
757
-          <xs:attribute name='url' use='required'/> 
757
+          <xs:attribute name='url' use='required'/>
758 758
         </xs:extension>
759 759
       </xs:simpleContent>
760 760
     </xs:complexType>
@@ -766,7 +766,7 @@ THE SOFTWARE.
766 766
     <xs:complexType>
767 767
       <xs:simpleContent>
768 768
         <xs:extension base='xs:string'>
769
-          <xs:attribute name='caption' use='optional'/> 
769
+          <xs:attribute name='caption' use='optional'/>
770 770
         </xs:extension>
771 771
       </xs:simpleContent>
772 772
     </xs:complexType>
@@ -776,7 +776,7 @@ THE SOFTWARE.
776 776
     <xs:complexType>
777 777
       <xs:simpleContent>
778 778
         <xs:extension base='xs:string'>
779
-          <xs:attribute name='caption' use='optional'/> 
779
+          <xs:attribute name='caption' use='optional'/>
780 780
         </xs:extension>
781 781
       </xs:simpleContent>
782 782
     </xs:complexType>
@@ -804,8 +804,8 @@ THE SOFTWARE.
804 804
     <xs:complexType>
805 805
       <xs:simpleContent>
806 806
         <xs:extension base='xs:string'>
807
-          <xs:attribute name='colspan' use='optional'/> 
808
-          <xs:attribute name='rowspan' use='optional'/> 
807
+          <xs:attribute name='colspan' use='optional'/>
808
+          <xs:attribute name='rowspan' use='optional'/>
809 809
         </xs:extension>
810 810
       </xs:simpleContent>
811 811
     </xs:complexType>
@@ -815,8 +815,8 @@ THE SOFTWARE.
815 815
     <xs:complexType>
816 816
       <xs:simpleContent>
817 817
         <xs:extension base='xs:string'>
818
-          <xs:attribute name='colspan' use='optional'/> 
819
-          <xs:attribute name='rowspan' use='optional'/> 
818
+          <xs:attribute name='colspan' use='optional'/>
819
+          <xs:attribute name='rowspan' use='optional'/>
820 820
         </xs:extension>
821 821
       </xs:simpleContent>
822 822
     </xs:complexType>

+ 8
- 8
xep-0004.xml View File

@@ -317,7 +317,7 @@
317 317
     type='get'
318 318
     xml:lang='en'
319 319
     id='create1'>
320
-  <command xmlns='http://jabber.org/protocol/commands' 
320
+  <command xmlns='http://jabber.org/protocol/commands'
321 321
            node='create'
322 322
            action='execute'/>
323 323
 </iq>
@@ -481,7 +481,7 @@
481 481
     type='get'
482 482
     xml:lang='en'
483 483
     id='search1'>
484
-  <command xmlns='http://jabber.org/protocol/commands' 
484
+  <command xmlns='http://jabber.org/protocol/commands'
485 485
            node='search'
486 486
            action='execute'/>
487 487
 </iq>
@@ -492,7 +492,7 @@
492 492
     type='result'
493 493
     xml:lang='en'
494 494
     id='search1'>
495
-  <command xmlns='http://jabber.org/protocol/commands' 
495
+  <command xmlns='http://jabber.org/protocol/commands'
496 496
            node='search'
497 497
            status='executing'>
498 498
     <x xmlns='jabber:x:data' type='form'>
@@ -512,7 +512,7 @@
512 512
     type='get'
513 513
     xml:lang='en'
514 514
     id='search2'>
515
-  <command xmlns='http://jabber.org/protocol/commands' 
515
+  <command xmlns='http://jabber.org/protocol/commands'
516 516
            node='search'>
517 517
     <x xmlns='jabber:x:data' type='submit'>
518 518
       <field type='text-single' var='search_request'>
@@ -528,7 +528,7 @@
528 528
     type='result'
529 529
     xml:lang='en'
530 530
     id='search2'>
531
-  <command xmlns='http://jabber.org/protocol/commands' 
531
+  <command xmlns='http://jabber.org/protocol/commands'
532 532
            node='search'
533 533
            status='completed'>
534 534
     <x xmlns='jabber:x:data' type='result'>
@@ -642,9 +642,9 @@
642 642
   <xs:element name='x'>
643 643
     <xs:complexType>
644 644
       <xs:sequence>
645
-        <xs:element name='instructions' 
646
-                    minOccurs='0' 
647
-                    maxOccurs='unbounded' 
645
+        <xs:element name='instructions'
646
+                    minOccurs='0'
647
+                    maxOccurs='unbounded'
648 648
                     type='xs:string'/>
649 649
         <xs:element name='title' minOccurs='0' type='xs:string'/>
650 650
         <xs:element ref='field' minOccurs='0' maxOccurs='unbounded'/>

+ 1
- 1
xep-0007.xml View File

@@ -70,7 +70,7 @@
70 70
     <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>
71 71
   </ul>
72 72
   <p>This new conferencing protocol will be designed to solve these problems.</p>
73
-  <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> 
73
+  <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>
74 74
 </section1>
75 75
 <section1 topic='Continuing Development'>
76 76
   <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 @@
5 5
 ]>
6 6
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
7 7
 <xep>
8
-<header>	
8
+<header>
9 9
   <title>Jabber-RPC</title>
10 10
   <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>
11 11
   &LEGALNOTICE;
@@ -74,9 +74,9 @@
74 74
 </section1>
75 75
 <section1 topic='Examples'>
76 76
   <example caption='A typical request'><![CDATA[
77
-<iq type='set' 
78
-    from='requester@company-b.com/jrpc-client' 
79
-    to='responder@company-a.com/jrpc-server' 
77
+<iq type='set'
78
+    from='requester@company-b.com/jrpc-client'
79
+    to='responder@company-a.com/jrpc-server'
80 80
     id='rpc1'>
81 81
   <query xmlns='jabber:iq:rpc'>
82 82
     <methodCall>
@@ -91,9 +91,9 @@
91 91
 </iq>
92 92
   ]]></example>
93 93
   <example caption='A typical response'><![CDATA[
94
-<iq type='result' 
95
-    from='responder@company-a.com/jrpc-server' 
96
-    to='requester@company-b.com/jrpc-client' 
94
+<iq type='result'
95
+    from='responder@company-a.com/jrpc-server'
96
+    to='requester@company-b.com/jrpc-client'
97 97
     id='rpc1'>
98 98
   <query xmlns='jabber:iq:rpc'>
99 99
     <methodResponse>
@@ -108,9 +108,9 @@
108 108
   ]]></example>
109 109
   <p>If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:</p>
110 110
   <example caption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[
111
-<iq type='error' 
112
-    from='responder@company-a.com/jrpc-server' 
113
-    to='requester@company-b.com/jrpc-client' 
111
+<iq type='error'
112
+    from='responder@company-a.com/jrpc-server'
113
+    to='requester@company-b.com/jrpc-client'
114 114
     id='rpc1'>
115 115
   <query xmlns='jabber:iq:rpc'>
116 116
     <methodCall>
@@ -131,17 +131,17 @@
131 131
 <section1 topic='Service Discovery' anchor='disco'>
132 132
   <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>
133 133
   <example caption='A disco#info query'><![CDATA[
134
-<iq type='get' 
135
-    from='requester@company-b.com/jrpc-client' 
136
-    to='responder@company-a.com/jrpc-server' 
134
+<iq type='get'
135
+    from='requester@company-b.com/jrpc-client'
136
+    to='responder@company-a.com/jrpc-server'
137 137
     id='disco1'>
138 138
   <query xmlns='http://jabber.org/protocol/disco#info'/>
139 139
 </iq>
140 140
   ]]></example>
141 141
   <example caption='A disco#info response'><![CDATA[
142
-<iq type='result' 
143
-    to='requester@company-b.com/jrpc-client' 
144
-    from='responder@company-a.com/jrpc-server' 
142
+<iq type='result'
143
+    to='requester@company-b.com/jrpc-client'
144
+    from='responder@company-a.com/jrpc-server'
145 145
     id='disco1'>
146 146
   <query xmlns='http://jabber.org/protocol/disco#info'>
147 147
     <identity category='automation' type='rpc'/>
@@ -179,9 +179,9 @@
179 179
       The protocol documented by this schema is defined in
180 180
       XEP-0009: http://www.xmpp.org/extensions/xep-0009.html
181 181
 
182
-      There is no official XML schema for XML-RPC. The main body 
183
-      of this schema has been borrowed from an unofficial schema 
184
-      representation contained in the book "Processing XML With 
182
+      There is no official XML schema for XML-RPC. The main body
183
+      of this schema has been borrowed from an unofficial schema
184
+      representation contained in the book "Processing XML With
185 185
       Java" by Elliotte Rusty Harold, as located at:
186 186
 
187 187
       http://www.ibiblio.org/xml/books/xmljava/chapters/ch02s05.html
@@ -210,13 +210,13 @@
210 210
         <xs:element name="params" minOccurs="0" maxOccurs="1">
211 211
           <xs:complexType>
212 212
             <xs:sequence>
213
-              <xs:element name="param"  type="ParamType" 
213
+              <xs:element name="param"  type="ParamType"
214 214
                            minOccurs="0" maxOccurs="unbounded"/>
215 215
             </xs:sequence>
216 216
           </xs:complexType>
217 217
          </xs:element>
218 218
       </xs:all>
219
-    </xs:complexType>  
219
+    </xs:complexType>
220 220
   </xs:element>
221 221
 
222 222
   <xs:element name="methodResponse">
@@ -236,13 +236,13 @@
236 236
               <xs:element name="value">
237 237
                 <xs:complexType>
238 238
                   <xs:sequence>
239
-                    <xs:element name="struct"> 
240
-                      <xs:complexType> 
241
-                        <xs:sequence> 
242
-                          <xs:element name="member" 
239
+                    <xs:element name="struct">
240
+                      <xs:complexType>
241
+                        <xs:sequence>
242
+                          <xs:element name="member"
243 243
                                        type="MemberType">
244 244
                           </xs:element>
245
-                          <xs:element name="member" 
245
+                          <xs:element name="member"
246 246
                                        type="MemberType">
247 247
                           </xs:element>
248 248
                         </xs:sequence>
@@ -255,7 +255,7 @@
255 255
           </xs:complexType>
256 256
          </xs:element>
257 257
       </xs:choice>
258
-    </xs:complexType>  
258
+    </xs:complexType>
259 259
   </xs:element>
260 260
 
261 261
   <xs:complexType name="ParamType">
@@ -286,7 +286,7 @@
286 286
 
287 287
   <xs:complexType name="StructType">
288 288
     <xs:sequence>
289
-      <xs:element name="member" type="MemberType" 
289
+      <xs:element name="member" type="MemberType"
290 290
                    maxOccurs="unbounded"/>
291 291
     </xs:sequence>
292 292
   </xs:complexType>
@@ -303,7 +303,7 @@
303 303
       <xs:element name="data">
304 304
         <xs:complexType>
305 305
           <xs:sequence>
306
-            <xs:element name="value"  type="ValueType" 
306
+            <xs:element name="value"  type="ValueType"
307 307
                          minOccurs="0" maxOccurs="unbounded"/>
308 308
           </xs:sequence>
309 309
         </xs:complexType>

+ 12
- 12
xep-0012.xml View File

@@ -81,7 +81,7 @@
81 81
 <section1 topic='Protocol' anchor='protocol'>
82 82
   <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>
83 83
   <example caption='Last Activity Query'><![CDATA[
84
-<iq from='romeo@montague.net/orchard' 
84
+<iq from='romeo@montague.net/orchard'
85 85
     id='last1'
86 86
     to='juliet@capulet.com'
87 87
     type='get'>
@@ -90,7 +90,7 @@
90 90
   ]]></example>
91 91
   <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>
92 92
   <example caption='Last Activity Response'><![CDATA[
93
-<iq from='juliet@capulet.com' 
93
+<iq from='juliet@capulet.com'
94 94
     id='last1'
95 95
     to='romeo@montague.net/orchard'
96 96
     type='result'>
@@ -108,7 +108,7 @@
108 108
 <section1 topic='Offline User Query' anchor='offline'>
109 109
   <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>
110 110
   <example caption='Last Activity Query'><![CDATA[
111
-<iq from='romeo@montague.net/orchard' 
111
+<iq from='romeo@montague.net/orchard'
112 112
     id='last1'
113 113
     to='juliet@capulet.com'
114 114
     type='get'>
@@ -118,9 +118,9 @@
118 118
   <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>
119 119
   <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>
120 120
   <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
121
-<iq from='juliet@capulet.com' 
121
+<iq from='juliet@capulet.com'
122 122
     id='last1'
123
-    to='romeo@montague.net/orchard' 
123
+    to='romeo@montague.net/orchard'
124 124
     type='error'>
125 125
   <error type='auth'>
126 126
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -152,7 +152,7 @@
152 152
   <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>
153 153
   <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>
154 154
   <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
155
-<iq from='juliet@capulet.com' 
155
+<iq from='juliet@capulet.com'
156 156
     id='last1'
157 157
     to='romeo@montague.net/orchard'
158 158
     type='error'>
@@ -163,9 +163,9 @@
163 163
   ]]></example>
164 164
   <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>
165 165
   <example caption='Last Activity Response by Client'><![CDATA[
166
-<iq from='juliet@capulet.com/balcony' 
166
+<iq from='juliet@capulet.com/balcony'
167 167
     id='last2'
168
-    to='romeo@montague.net/orchard' 
168
+    to='romeo@montague.net/orchard'
169 169
     type='result'>
170 170
   <query xmlns='jabber:iq:last' seconds='123'/>
171 171
 </iq>
@@ -173,7 +173,7 @@
173 173
   <p>In the foregoing example, the user has been idle for about two minutes.</p>
174 174
   <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>
175 175
   <example caption='Service Unavailable Error'><![CDATA[
176
-<iq from='juliet@capulet.com/balcony' 
176
+<iq from='juliet@capulet.com/balcony'
177 177
     id='last2'
178 178
     to='romeo@montague.net/orchard'
179 179
     type='error'>
@@ -187,15 +187,15 @@
187 187
 <section1 topic='Server and Component Query' anchor='server'>
188 188
   <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>
189 189
   <example caption='Last Activity Query Sent to Server or Service'><![CDATA[
190
-<iq from='romeo@montague.net/orchard' 
190
+<iq from='romeo@montague.net/orchard'
191 191
     id='last3'
192
-    to='capulet.com' 
192
+    to='capulet.com'
193 193
     type='get'>
194 194
   <query xmlns='jabber:iq:last'/>
195 195
 </iq>
196 196
   ]]></example>
197 197
   <example caption='Last Activity Response from Server or Service'><![CDATA[
198
-<iq from='capulet.com' 
198
+<iq from='capulet.com'
199 199
     id='last3'
200 200
     to='romeo@montague.net/orchard'
201 201
     type='result'>

+ 16
- 16
xep-0013.xml View File

@@ -122,12 +122,12 @@
122 122
     <p>In order to discover whether one's server supports this protocol, one uses &xep0030;.</p>
123 123
     <example caption='User Requests Service Discovery Information'><![CDATA[
124 124
 <iq type='get' to='montague.net'>
125
-  <query xmlns='http://jabber.org/protocol/disco#info'/> 
125
+  <query xmlns='http://jabber.org/protocol/disco#info'/>
126 126
 </iq>
127 127
     ]]></example>
128 128
     <example caption='Server Reply to Discovery Request'><![CDATA[
129
-<iq type='result' 
130
-    from='montague.net' 
129
+<iq type='result'
130
+    from='montague.net'
131 131
     to='romeo@montague.net/orchard'>
132 132
   <query xmlns='http://jabber.org/protocol/disco#info'>
133 133
     <feature var='http://jabber.org/protocol/offline'/>
@@ -141,7 +141,7 @@
141 141
     <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>
142 142
     <example caption='User Requests Information About Offline Message Node'><![CDATA[
143 143
 <iq type='get'>
144
-  <query xmlns='http://jabber.org/protocol/disco#info' 
144
+  <query xmlns='http://jabber.org/protocol/disco#info'
145 145
          node='http://jabber.org/protocol/offline'/>
146 146
 </iq>
147 147
     ]]></example>
@@ -171,32 +171,32 @@
171 171
     <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>
172 172
     <example caption='User Requests Offline Message Headers'><![CDATA[
173 173
 <iq type='get'>
174
-  <query xmlns='http://jabber.org/protocol/disco#items' 
174
+  <query xmlns='http://jabber.org/protocol/disco#items'
175 175
          node='http://jabber.org/protocol/offline'/>
176 176
 </iq>
177 177
     ]]></example>
178 178
     <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>
179 179
     <example caption='Server Provides Offline Message Headers'><![CDATA[
180 180
 <iq type='result' to='romeo@montague.net/orchard'>
181
-  <query xmlns='http://jabber.org/protocol/disco#items' 
181
+  <query xmlns='http://jabber.org/protocol/disco#items'
182 182
          node='http://jabber.org/protocol/offline'>
183
-    <item 
183
+    <item
184 184
         jid='romeo@montague.net'
185 185
         node='2003-02-27T22:49:17.008Z'
186 186
         name='mercutio@shakespeare.lit/pda'/>
187
-    <item 
187
+    <item
188 188
         jid='romeo@montague.net'
189 189
         node='2003-02-27T22:52:37.225Z'
190 190
         name='juliet@capulet.com/balcony'/>
191
-    <item 
191
+    <item
192 192
         jid='romeo@montague.net'
193 193
         node='2003-02-27T22:52:51.270Z'
194 194
         name='juliet@capulet.com/balcony'/>
195
-    <item 
195
+    <item
196 196
         jid='romeo@montague.net'
197 197
         node='2003-02-27T22:53:03.421Z'
198 198
         name='juliet@capulet.com/balcony'/>
199
-    <item 
199
+    <item
200 200
         jid='romeo@montague.net'
201 201
         node='2003-02-27T22:53:13.925Z'
202 202
         name='juliet@capulet.com/balcony'/>
@@ -298,7 +298,7 @@ S: <stream:stream ...>
298 298
 
299 299
 C: authentication (SASL in XMPP, non-SASL in older systems)
300 300
 
301
-S: acknowledge successful authentication 
301
+S: acknowledge successful authentication
302 302
 
303 303
 C: <presence/>
304 304
 
@@ -315,7 +315,7 @@ S: <stream:stream ...>
315 315
 
316 316
 C: authentication (SASL in XMPP, non-SASL in older systems)
317 317
 
318
-S: acknowledge successful authentication 
318
+S: acknowledge successful authentication
319 319
 
320 320
 C: request message headers
321 321
 
@@ -325,7 +325,7 @@ NOTE: Server now MUST NOT flood Client with offline messages.
325 325
 
326 326
 C: <presence/>
327 327
 
328
-NOTE: Server does not flood Client with offline messages, but 
328
+NOTE: Server does not flood Client with offline messages, but
329 329
       sends in-session messages as usual.
330 330
 
331 331
 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 363
     <type>
364 364
       <name>message-list</name>
365 365
       <desc>
366
-        The node for the offline message queue; valid only for the node 
366
+        The node for the offline message queue; valid only for the node
367 367
         "http://jabber.org/protocol/offline"
368 368
       </desc>
369 369
       <doc>XEP-0013</doc>
@@ -371,7 +371,7 @@ C: request and remove offline messages, send and receive messages, etc.
371 371
     <type>
372 372
       <name>message-node</name>
373 373
       <desc>
374
-        A node for a specific offline message if service discovery is 
374
+        A node for a specific offline message if service discovery is
375 375
         provided for messages
376 376
       </desc>
377 377
       <doc>XEP-0013</doc>

+ 1
- 1
xep-0018.xml View File

@@ -119,7 +119,7 @@
119 119
       <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">
120 120
     <show>chat</show>
121 121
 </presence>
122
-    
122
+
123 123
 <presence from="joe@foo.com/resource" to="rynok@foo.com/resource">
124 124
     <show>chat</show>
125 125
 </presence>]]></example>

+ 1
- 1
xep-0019.xml View File

@@ -52,7 +52,7 @@
52 52
   <ol>
53 53
     <li>"Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
54 54
     <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>
55
-    <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>  
55
+    <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>
56 56
   </ol>
57 57
   <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>
58 58
   <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 @@
48 48
    <li>User's avatar has changed</li>
49 49
    <li>The coffee machine is empty</li>
50 50
   </ul>
51
-  
51
+
52 52
   <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>
53 53
 
54 54
   <ul>
55 55
    <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>
56 56
    <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>
57 57
   </ul>
58
-  
58
+
59 59
   <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>
60 60
 
61 61
   <p>The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.</p>
@@ -187,7 +187,7 @@
187 187
     </example>
188 188
 
189 189
     <p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
190
-    
190
+
191 191
     <example caption='Event notification (publish) with payload'>
192 192
 &lt;iq id='enspub2' type='set' from='ens-jid' to='subscriber-jid'&gt;
193 193
   &lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'&gt;
@@ -225,7 +225,7 @@
225 225
     </example>
226 226
 
227 227
     <p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
228
-    
228
+
229 229
     <example caption='Event notification (publish) with payload'>
230 230
 &lt;iq id='pub1' type='set' from='event-jid' to='ens-jid'&gt;
231 231
   &lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/'&gt;
@@ -257,7 +257,7 @@
257 257
     </example>
258 258
 
259 259
     <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>
260
-    
260
+
261 261
     <example caption='Authorisation request with authorisation information'>
262 262
 &lt;iq id='ensauth1' type='get' from='ens-jid' to='event-jid'&gt;
263 263
   &lt;authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'&gt;
@@ -270,7 +270,7 @@
270 270
 
271 271
   <section2 topic='Authorisation response'>
272 272
     <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>
273
-    
273
+
274 274
     <example caption='Successful authorisation response'>
275 275
 &lt;iq id='ensauth1' type='result' from='event-jid' to='ens-jid'&gt;
276 276
   &lt;authorised xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/&gt;
@@ -310,7 +310,7 @@
310 310
       <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>
311 311
       <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>
312 312
     </ul>
313
-    
313
+
314 314
     <p>This problem may be outside of the scope of this specification.</p>
315 315
   </section2>
316 316
 

+ 48
- 48
xep-0024.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Publish/Subscribe</title>
10
-  <abstract>A publish-subscribe protocol for Jabber.</abstract> 
10
+  <abstract>A publish-subscribe protocol for Jabber.</abstract>
11 11
   &PUBLICDOMAINNOTICE;
12 12
   <number>0024</number>
13 13
   <status>Retracted</status>
@@ -64,7 +64,7 @@ two separate but related goals:
64 64
 
65 65
 <p>
66 66
 The specification details the use of the Jabber protocol elements and
67
-introduces a new namespace, jabber:iq:pubsub. 
67
+introduces a new namespace, jabber:iq:pubsub.
68 68
 It also includes notes on actual implementation of such a
69 69
 mechanism in Jabber.
70 70
 </p>
@@ -78,7 +78,7 @@ It's clear that as Jabber is deployed over a wider spectrum of platforms
78 78
 and circumstances, more and more information will be exchanged. Whether
79 79
 that information is specific to Jabber (JSM) users, or components, we need
80 80
 an mechanism to be able to manage the exchange of this information in an
81
-efficient way. 
81
+efficient way.
82 82
 </p>
83 83
 
84 84
 <p>
@@ -301,7 +301,7 @@ You can also send an unsubscribe without specifying any namespaces:
301 301
 </p>
302 302
 
303 303
 <example caption='Publisher-specific general unsubscription'>
304
-SEND: &lt;iq type='set' to='pubsub.localhost' 
304
+SEND: &lt;iq type='set' to='pubsub.localhost'
305 305
              from='subscriber.localhost' id='s1'&gt;
306 306
         &lt;query xmlns='jabber:iq:pubsub'&gt;
307 307
           &lt;unsubscribe to='publisher'/&gt;
@@ -392,7 +392,7 @@ Likewise, you can unsubscribe from certain namespaces in this non-publisher-spec
392 392
 </p>
393 393
 
394 394
 <example caption='General unsubscription to specific namespaces'>
395
-SEND: &lt;iq type='set' to='pubsub.localhost' 
395
+SEND: &lt;iq type='set' to='pubsub.localhost'
396 396
              from='subscriber.localhost' id='s1'&gt;
397 397
         &lt;query xmlns='jabber:iq:pubsub'&gt;
398 398
           &lt;unsubscribe&gt;
@@ -402,7 +402,7 @@ SEND: &lt;iq type='set' to='pubsub.localhost'
402 402
         &lt;/query&gt;
403 403
       &lt;/iq&gt;
404 404
 
405
-RECV: &lt;iq type='result' from='pubsub.localhost' 
405
+RECV: &lt;iq type='result' from='pubsub.localhost'
406 406
              to='subscriber.localhost' id='s1'&gt;
407 407
         &lt;query xmlns='jabber:iq:pubsub'&gt;
408 408
           &lt;unsubscribe&gt;
@@ -424,14 +424,14 @@ Finally, a subscriber can wipe the slate clean like this:
424 424
 </p>
425 425
 
426 426
 <example caption='Wiping the slate'>
427
-SEND: &lt;iq type='set' to='pubsub.localhost' 
427
+SEND: &lt;iq type='set' to='pubsub.localhost'
428 428
              from='subscriber.localhost' id='s1'&gt;
429 429
         &lt;query xmlns='jabber:iq:pubsub'&gt;
430 430
           &lt;unsubscribe/&gt;
431 431
         &lt;/query&gt;
432 432
       &lt;/iq&gt;
433 433
 
434
-RECV: &lt;iq type='result' from='pubsub.localhost' 
434
+RECV: &lt;iq type='result' from='pubsub.localhost'
435 435
              to='subscriber.localhost' id='s1'&gt;
436 436
         &lt;query xmlns='jabber:iq:pubsub'&gt;
437 437
           &lt;unsubscribe/&gt;
@@ -644,7 +644,7 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
644 644
 
645 645
 <!--
646 646
 <p>
647
-Optionally, a pubsub component may respond with an empty IQ-result, to 
647
+Optionally, a pubsub component may respond with an empty IQ-result, to
648 648
 reduce traffic:
649 649
 </p>
650 650
 
@@ -657,13 +657,13 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
657 657
 
658 658
 <p>
659 659
 Each published item is wrapped in a &lt;publish/&gt; tag. This tag
660
-must contain the namespace of the item being publishes, in an ns 
660
+must contain the namespace of the item being publishes, in an ns
661 661
 attribute, as shown. This is distinct from the xmlns attribute of
662 662
 the fragment of XML actually being published. It is theoretically
663 663
 none of the pubsub component's business to go poking around in the
664 664
 real published data, nor should it have to. It needs to know what
665
-namespace is qualifying the published information that has been 
666
-received, so that the list of appropriate recipients can be 
665
+namespace is qualifying the published information that has been
666
+received, so that the list of appropriate recipients can be
667 667
 determined.
668 668
 </p>
669 669
 
@@ -674,7 +674,7 @@ determined.
674 674
 <p>
675 675
 While it's the responsibility of the publishing entities to publish
676 676
 information, it's the responsibility of the pubsub
677
-component to push out that published data to the subscribers. The 
677
+component to push out that published data to the subscribers. The
678 678
 list of recipient subscribers must be determined by the information
679 679
 stored by the pubsub component as a result of receiving subscription
680 680
 requests (which are described earlier).
@@ -694,7 +694,7 @@ fragments of published data.</note>
694 694
 <p>
695 695
 Taking the earlier example of the publishing of data in the 'foo'
696 696
 namespace, the following example shows what the pubsub component
697
-must send to push this foo data out to a subscriber. 
697
+must send to push this foo data out to a subscriber.
698 698
 </p>
699 699
 <example caption='Pushing out published information to a subscriber'>
700 700
 SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
@@ -707,7 +707,7 @@ SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
707 707
       &lt;/iq&gt;
708 708
 </example>
709 709
 <p>
710
-The recipient is _not_ required to send an 'acknowledgement' in the 
710
+The recipient is _not_ required to send an 'acknowledgement' in the
711 711
 form of an IQ-result; the idea that this _push_ of information is
712 712
 akin to how information is pushed in a live browsing context (see
713 713
 jabber:iq:browse documentation for more details).
@@ -720,7 +720,7 @@ jabber:iq:browse documentation for more details).
720 720
 <p>
721 721
 When a pubsub service receives a publish packet like the ones above, it
722 722
 needs to deliver (push) the information out according to the subscriptions
723
-that have been made. 
723
+that have been made.
724 724
 </p>
725 725
 
726 726
 <p>
@@ -729,7 +729,7 @@ subscription between the pubsub service and the subscriber(s). If the
729 729
 subscriber wishes only to receive information when he's online (this is
730 730
 a JSM-specific issue), then he needs to set up a presence subscription
731 731
 relationship with the pubsub service. The pubsub service should respond
732
-to presence subscriptions and unsubscriptions by 
732
+to presence subscriptions and unsubscriptions by
733 733
 </p>
734 734
 
735 735
 <ul>
@@ -740,16 +740,16 @@ to presence subscriptions and unsubscriptions by
740 740
 <p>
741 741
 If the pubsub service deems that a published piece of information should
742 742
 be pushed to a subscriber, and there is a presence subscription relationship
743
-with that subscriber, the service should only push that information to the 
743
+with that subscriber, the service should only push that information to the
744 744
 subscriber if he is available. If he is not available, the information is not
745
-to be sent. 
745
+to be sent.
746 746
 </p>
747 747
 
748 748
 <p>
749 749
 Thus the subscriber can control the sensitivity by initiating (or not) a
750 750
 presence relationship with the service. If the subscriber wishes to receive
751 751
 information regardless of availability, he should not initiate a (or cancel
752
-any previous) presence relationship with the service. 
752
+any previous) presence relationship with the service.
753 753
 </p>
754 754
 
755 755
 <p>
@@ -762,7 +762,7 @@ publish/subscribe where presence is not a given.
762 762
 
763 763
 <section2 topic='Use of Resources'>
764 764
 <p>
765
-When in receipt of a pubsub subscription request from an entity 
765
+When in receipt of a pubsub subscription request from an entity
766 766
 where a resource is specified in the JID, the pubsub component must
767 767
 honour the resource specified in the from attribute of the request.
768 768
 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 780
 </example>
781 781
 <p>
782 782
 When storing the subscriber/publisher/namespace relationship matrix for
783
-eventual querying when a publisher publishes some information, the 
783
+eventual querying when a publisher publishes some information, the
784 784
 pubsub component must use the full JID, not just the username@host part.
785 785
 </p>
786 786
 <p>
@@ -802,7 +802,7 @@ the full JID of the component subscriber - news.server/politics-listener,
802 802
 should be used to qualify the matrix.
803 803
 </p>
804 804
 <p>
805
-This is because it allows the subscribing entities to arrange the 
805
+This is because it allows the subscribing entities to arrange the
806 806
 receipt of pushed items by resource. In the case of a JSM user, it
807 807
 allows him to organise his clients, which may have different capabilities
808 808
 (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 828
 
829 829
 <section2 topic='Publisher Discovery'>
830 830
 <p>
831
-There is no part of this pubsub specification that determines how a 
831
+There is no part of this pubsub specification that determines how a
832 832
 potential subscriber might discover publishers. After all, there are
833 833
 no rules governing which pubsub component a publisher could or should
834 834
 publish to. And since pubsub subscriptions are specific to a pubsub
835
-component, there is an information gap - "how do I find out what 
835
+component, there is an information gap - "how do I find out what
836 836
 publishers there are, and through which pubsub components they're publishing
837 837
 information?"
838 838
 </p>
@@ -857,7 +857,7 @@ here). The next two sections look at how these things might pan out.
857 857
 
858 858
 <section2 topic='Cross-Server Relationships'>
859 859
 <p>
860
-When JSM users on server1 wish to subscribe to information published 
860
+When JSM users on server1 wish to subscribe to information published
861 861
 by JSM users on server2 (let's say it's the mp3 player info, or avatars)
862 862
 then there are some issues that come immediately to mind:
863 863
 </p>
@@ -865,9 +865,9 @@ then there are some issues that come immediately to mind:
865 865
 <li>Does a JSM user on server1 (userA@server1) send his IQ-set subscription
866 866
 to the pubsub component on server2 (pubsub.server2), or server1
867 867
 (pubsub.server1)?</li>
868
-<li>If he sends it to pubsub.server2, can we expect 
869
-pubsub.server2 to always accept that subscription request, i.e. to 
870
-be willing to serve userA@server1 (if pubsub.server2 knows that 
868
+<li>If he sends it to pubsub.server2, can we expect
869
+pubsub.server2 to always accept that subscription request, i.e. to
870
+be willing to serve userA@server1 (if pubsub.server2 knows that
871 871
 pubsub.server1 exists)?</li>
872 872
 <li>Will there be performance (or at least server-to-server traffic)
873 873
 implications if many subscription relationships exist between subscribers on
@@ -876,7 +876,7 @@ server1 and publishers on server2?</li>
876 876
 
877 877
 <section3 topic='Proxy Subscriptions'>
878 878
 <p>
879
-To reduce the amount of server-to-server traffic, we can employ the 
879
+To reduce the amount of server-to-server traffic, we can employ the
880 880
 concept of "proxy subscriptions". This is simply getting a pubsub component
881 881
 to act on behalf of a (server-local) subscriber. Benefit comes when a pubsub
882 882
 component acts on behalf of multiple (server-local) subscribers.
@@ -889,7 +889,7 @@ server-to-server traffic:
889 889
 Step 1: Subscriber sends original subscription
890 890
 </p>
891 891
 <p>
892
-JSM users on server1 wish to subscribe to information published by an 
892
+JSM users on server1 wish to subscribe to information published by an
893 893
 entity on server2. Each of them sends a subscription request to the
894 894
 _local_ pubsub component:
895 895
 </p>
@@ -925,7 +925,7 @@ SEND: &lt;iq type='set' to='pubsub.server2'
925 925
 
926 926
 <p>
927 927
 The remote pubsub component receives and acknowledges the subscription
928
-request, and the local pubsub component relays the response back to 
928
+request, and the local pubsub component relays the response back to
929 929
 the original requester:
930 930
 </p>
931 931
 <example>
@@ -940,7 +940,7 @@ SEND: &lt;iq type='result' from='pubsub.server1'
940 940
 </example>
941 941
 
942 942
 <p>
943
-If the remote pubsub server was unable or unwilling to accept the 
943
+If the remote pubsub server was unable or unwilling to accept the
944 944
 subscription request, this should be reflected in the response:
945 945
 </p>
946 946
 <example>
@@ -959,7 +959,7 @@ SEND: &lt;iq type='error' from='pubsub.server1'
959 959
 Step3: Publisher publishes information
960 960
 </p>
961 961
 <p>
962
-The publisher, publisher.server2, publishes information in the 
962
+The publisher, publisher.server2, publishes information in the
963 963
 namespace:1 namespace, to the remote pubsub component pubsub.server2:
964 964
 </p>
965 965
 <example>
@@ -1022,18 +1022,18 @@ where publisher entities publish their information.
1022 1022
 This knowledge, and the mechanisms to discover this sort of information,
1023 1023
 is not to be covered in this spec, which purely deals with the subscription
1024 1024
 and publishing of information. As SOAP is to UDDI (to use a slightly
1025
-controversial pair of technologies), so is jabber:iq:pubsub to this 
1025
+controversial pair of technologies), so is jabber:iq:pubsub to this
1026 1026
 discovery mechanism as yet undefined. To include the definition of such
1027 1027
 a discovery mechanism in this specification is wrong on two counts:
1028 1028
 </p>
1029 1029
 <ul>
1030 1030
 <li>Discovery mechanisms by nature should not be tied to specific areas</li>
1031
-<li>Trying to load too much onto jabber:iq:pubsub will only produce a 
1031
+<li>Trying to load too much onto jabber:iq:pubsub will only produce a
1032 1032
 complex and hard-to-implement specification</li>
1033 1033
 </ul>
1034 1034
 <p>
1035 1035
 After all, the jabber:iq:pubsub spec as defined here is usable out of the
1036
-box for the simple scenarios, and scenarios where discovery is not 
1036
+box for the simple scenarios, and scenarios where discovery is not
1037 1037
 necessary or the information can be exchanged in other ways.
1038 1038
 </p>
1039 1039
 
@@ -1042,7 +1042,7 @@ necessary or the information can be exchanged in other ways.
1042 1042
 <section3 topic='Willingness to Serve'>
1043 1043
 <p>
1044 1044
 There are some situations where it might be appropriate for a pubsub
1045
-component to refuse particular subscription requests. Here are two 
1045
+component to refuse particular subscription requests. Here are two
1046 1046
 examples:
1047 1047
 </p>
1048 1048
 <ul>
@@ -1051,11 +1051,11 @@ configured to handle local-only pubsub traffic, and a subscription request
1051 1051
 is received, specifying a publisher that the local pubsub component knows
1052 1052
 to be one that publishes to a remote pubsub component <note>under other
1053 1053
 circumstances, this would trigger a 'Proxy Subscription', as described earlier, if supported</note>. In this case, the local pubsub component would be
1054
-unwilling to provoke a server-to-server connection and therefore unwilling to 
1054
+unwilling to provoke a server-to-server connection and therefore unwilling to
1055 1055
 honour the request.</li>
1056
-<li>Where a pubsub component receives a subscription request from a 
1057
-remote subscriber, and that pubsub component knows that there's a 
1058
-pubsub component local to the subscriber. In this case, the (administrator 
1056
+<li>Where a pubsub component receives a subscription request from a
1057
+remote subscriber, and that pubsub component knows that there's a
1058
+pubsub component local to the subscriber. In this case, the (administrator
1059 1059
 of the) remote pubsub component might want to encourage proxy subscriptions.
1060 1060
 </li>
1061 1061
 </ul>
@@ -1093,20 +1093,20 @@ but it's an interesting concept :-)</p>
1093 1093
 
1094 1094
 <section2 topic='Subscriber Anonymity and Acceptance?'>
1095 1095
 <p>
1096
-The jabber:iq:pubsub specification makes no provision for 
1096
+The jabber:iq:pubsub specification makes no provision for
1097 1097
 publishers to query a pubsub component to ask for a list of those entities
1098
-that are subscribed to (namespaces) it (publishes). This is deliberate. 
1098
+that are subscribed to (namespaces) it (publishes). This is deliberate.
1099 1099
 Do we wish to add to the specification to allow the publisher to discover
1100 1100
 this information? If so, it must be as an optional 'opt-in' (or 'opt-out')
1101 1101
 tag for the subscriber, to determine whether his JID will show up on the
1102
-list. 
1102
+list.
1103 1103
 <note>Even if there is no provision for querying the subscribers, perhaps
1104 1104
 we should make a provision for the publisher to ask the pubsub component
1105 1105
 for a list of namespaces that have been subscribed to (for that publisher).
1106 1106
 </note>
1107 1107
 </p>
1108 1108
 <p>
1109
-Associated with this is the semi-reciprocal issue of acceptance? The 
1109
+Associated with this is the semi-reciprocal issue of acceptance? The
1110 1110
 specification deliberately makes no provision for a subscription acceptance
1111 1111
 mechanism (where the publisher must first accept a subscriber's request,
1112 1112
 via the pubsub component). If we're to prevent the publishers knowing
@@ -1115,11 +1115,11 @@ things out'?
1115 1115
 </p>
1116 1116
 <p>
1117 1117
 Note that if we do, the acceptance issue is not necessarily one for the
1118
-pubsub specification to resolve; there are other ways of introducing 
1118
+pubsub specification to resolve; there are other ways of introducing
1119 1119
 access control, at least in a component environment; use of a mechanism
1120 1120
 that the Jabber::Component::Proxy Perl module represents is one example:
1121 1121
 wedge a proxy component in front of a real (pubsub) component and have
1122
-the ability to use ACLs (access control lists) to control who gets to 
1122
+the ability to use ACLs (access control lists) to control who gets to
1123 1123
 connect to the real component.
1124 1124
 </p>
1125 1125
 

+ 3
- 3
xep-0025.xml View File

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

+ 8
- 8
xep-0026.xml View File

@@ -89,7 +89,7 @@
89 89
 			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;.
90 90
 		</p>
91 91
 	</section2>
92
-	
92
+
93 93
 	<section2 topic='Client support'>
94 94
 		<p>
95 95
 			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 115
 		</p>
116 116
 	</section2>
117 117
 
118
-	
118
+
119 119
 	<section2 topic='Server support'>
120 120
 		<p>
121
-			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. 
121
+			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.
122 122
 		</p>
123 123
 		<p>
124 124
 			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 134
 		</p>
135 135
 	</section2>
136 136
 
137
-	
137
+
138 138
 	<section2 topic='Service support'>
139 139
 		<p>
140 140
 			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 152
 
153 153
     &lt;x xmlns='jabber:x:data'&gt;
154 154
       &lt;instructions&gt;
155
-          To search for a user fill out at least one 
155
+          To search for a user fill out at least one
156 156
           of the fields below and submit the form.
157 157
       &lt;/instructions&gt;
158 158
       &lt;field type='text-single' label='First (Given)' var='first'/&gt;
@@ -179,7 +179,7 @@
179 179
 &lt;iq from='users.jabber.org' type='result' id='5' xml:lang='de'&gt;
180 180
   &lt;query xmlns='jabber:iq:search'&gt;
181 181
     &lt;instructions&gt;
182
-        F&#252;llen Sie ein Feld aus um nach einem beliebigen 
182
+        F&#252;llen Sie ein Feld aus um nach einem beliebigen
183 183
         passenden Jabber-Benutzer zu suchen.
184 184
     &lt;/instructions&gt;
185 185
     &lt;nick/&gt;
@@ -189,7 +189,7 @@
189 189
 
190 190
     &lt;x xmlns='jabber:x:data'&gt;
191 191
       &lt;instructions&gt;
192
-          Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines 
192
+          Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines
193 193
           der folgenden Felder aus und schicken dann das Formular ab.
194 194
       &lt;/instructions&gt;
195 195
       &lt;field type='text-single' label='Vorname' var='first'/&gt;
@@ -202,7 +202,7 @@
202 202
 		<p>
203 203
 			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).
204 204
      	</p>
205
-     
205
+
206 206
 	</section2>
207 207
 </section1>
208 208
 

+ 11
- 11
xep-0029.xml View File

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

+ 13
- 13
xep-0030.xml View File

@@ -410,7 +410,7 @@
410 410
     from='romeo@montague.net/orchard'
411 411
     to='mim.shakespeare.lit'
412 412
     id='info3'>
413
-  <query xmlns='http://jabber.org/protocol/disco#info' 
413
+  <query xmlns='http://jabber.org/protocol/disco#info'
414 414
          node='http://jabber.org/protocol/commands'/>
415 415
 </iq>
416 416
       ]]></example>
@@ -420,7 +420,7 @@
420 420
     from='mim.shakespeare.lit'
421 421
     to='romeo@montague.net/orchard'
422 422
     id='info3'>
423
-  <query xmlns='http://jabber.org/protocol/disco#info' 
423
+  <query xmlns='http://jabber.org/protocol/disco#info'
424 424
          node='http://jabber.org/protocol/commands'>
425 425
     <identity
426 426
         category='automation'
@@ -538,7 +538,7 @@
538 538
     from='romeo@montague.net/orchard'
539 539
     to='catalog.shakespeare.lit'
540 540
     id='items3'>
541
-  <query xmlns='http://jabber.org/protocol/disco#items' 
541
+  <query xmlns='http://jabber.org/protocol/disco#items'
542 542
          node='music'/>
543 543
 </iq>
544 544
       ]]></example>
@@ -548,7 +548,7 @@
548 548
     from='catalog.shakespeare.lit'
549 549
     to='romeo@montague.net/orchard'
550 550
     id='items3'>
551
-  <query xmlns='http://jabber.org/protocol/disco#items' 
551
+  <query xmlns='http://jabber.org/protocol/disco#items'
552 552
          node='music'>
553 553
     <item jid='catalog.shakespeare.lit'
554 554
           node='music/A'/>
@@ -570,7 +570,7 @@
570 570
     from='romeo@montague.net/orchard'
571 571
     to='catalog.shakespeare.lit'
572 572
     id='items4'>
573
-  <query xmlns='http://jabber.org/protocol/disco#items' 
573
+  <query xmlns='http://jabber.org/protocol/disco#items'
574 574
          node='music/D'/>
575 575
 </iq>
576 576
       ]]></example>
@@ -579,7 +579,7 @@
579 579
     from='catalog.shakespeare.lit'
580 580
     to='romeo@montague.net/orchard'
581 581
     id='items4'>
582
-  <query xmlns='http://jabber.org/protocol/disco#items' 
582
+  <query xmlns='http://jabber.org/protocol/disco#items'
583 583
          node='music/D'>
584 584
     <item jid='catalog.shakespeare.lit'
585 585
           node='music/D/dowland-firstbooke'
@@ -613,17 +613,17 @@
613 613
     id='items4'
614 614
     to='romeo@montague.net'
615 615
     type='get'>
616
-  <query xmlns='http://jabber.org/protocol/disco#items' 
616
+  <query xmlns='http://jabber.org/protocol/disco#items'
617 617
          node='http://jabber.org/protocol/tune'/>
618 618
 </iq>
619 619
       ]]></example>
620
-      <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> 
620
+      <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>
621 621
       <example caption='Entity returns multiple items'><![CDATA[
622 622
 <iq from='romeo@montague.net'
623 623
     id='items4'
624 624
     to='juliet@capulet.com/chamber'
625 625
     type='result'>
626
-  <query xmlns='http://jabber.org/protocol/disco#items' 
626
+  <query xmlns='http://jabber.org/protocol/disco#items'
627 627
          node='http://jabber.org/protocol/tune'>
628 628
     <item jid='pubsub.shakespeare.lit'
629 629
           name='Romeo&apos;s CD player'
@@ -661,7 +661,7 @@
661 661
     from='mim.shakespeare.lit'
662 662
     to='romeo@montague.net/orchard'
663 663
     id='info3'>
664
-  <query xmlns='http://jabber.org/protocol/disco#info' 
664
+  <query xmlns='http://jabber.org/protocol/disco#info'
665 665
          node='http://jabber.org/protocol/commands'/>
666 666
   <error type='cancel'>
667 667
     <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -740,13 +740,13 @@
740 740
 <category>
741 741
   <name>hierarchy</name>
742 742
   <desc>
743
-    An entity that exists in the context of a 
743
+    An entity that exists in the context of a
744 744
     service discovery node hierarchy.
745 745
   </desc>
746 746
   <type>
747 747
     <name>branch</name>
748 748
     <desc>
749
-      A "container node" for other entities in a 
749
+      A "container node" for other entities in a
750 750
       service discovery node hierarchy.
751 751
     </desc>
752 752
     <doc>XEP-0030</doc>
@@ -754,7 +754,7 @@
754 754
   <type>
755 755
     <name>leaf</name>
756 756
     <desc>
757
-      A "terminal node" in a service discovery 
757
+      A "terminal node" in a service discovery
758 758
       node hierarchy.
759 759
     </desc>
760 760
     <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 @@
67 67
   </section2>
68 68
   <section2 topic='Node Identifier Component'>
69 69
     <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>
70
-    <code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) | 
71
-#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) | 
70
+    <code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
71
+#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
72 72
 #x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
73
-    <p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p> 
73
+    <p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
74 74
     <code>#x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)</code>
75 75
     <p>Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:</p>
76 76
     <code>#x23 (#) | #x25 (%)</code>
@@ -82,10 +82,10 @@
82 82
   </section2>
83 83
   <section2 topic='Query Component'>
84 84
     <p>The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:</p>
85
-    <code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) | 
86
-#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) | 
87
-#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) | 
88
-#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) | 
85
+    <code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
86
+#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) |
87
+#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) |
88
+#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) |
89 89
 #x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
90 90
   </section2>
91 91
 </section1>

+ 16
- 16
xep-0033.xml View File

@@ -6,7 +6,7 @@
6 6
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
7 7
 <xep>
8 8
     <header>
9
-        <title>Extended Stanza Addressing</title> 
9
+        <title>Extended Stanza Addressing</title>
10 10
         <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>
11 11
         &LEGALNOTICE;
12 12
         <number>0033</number>
@@ -55,7 +55,7 @@
55 55
             <version>0.10</version>
56 56
             <date>2004-03-18</date>
57 57
             <initials>psa</initials>
58
-            <remark>Disallowed &lt;addresses/&gt; as direct child 
58
+            <remark>Disallowed &lt;addresses/&gt; as direct child
59 59
             of &IQ;.</remark>
60 60
         </revision>
61 61
 
@@ -143,12 +143,12 @@
143 143
     </header>
144 144
     <section1 topic='Introduction' anchor='intro'>
145 145
             <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>
146
-      
146
+
147 147
             <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>
148 148
     </section1>
149 149
     <section1 topic='Discovering Server Support' anchor='disco'>
150 150
         <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>
151
-        
151
+
152 152
         <section2 topic='Disco to determine support' anchor='disco-support'>
153 153
             <p>To determine if a server or service supports Extended Stanza Addressing, the requesting entity SHOULD send a disco#info request to it.</p>
154 154
 
@@ -210,7 +210,7 @@
210 210
         relaying across server-to-server connections as a side-effect.</p>
211 211
 
212 212
         <p>Address headers MAY be included in message or presence
213
-        stanzas.  They MUST NOT be included as the direct child of an 
213
+        stanzas.  They MUST NOT be included as the direct child of an
214 214
         IQ stanza.</p>
215 215
     </section1>
216 216
 
@@ -233,7 +233,7 @@
233 233
     </addresses>
234 234
 </presence>]]></example>
235 235
 
236
-        
236
+
237 237
         <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>
238 238
 
239 239
         <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 @@
294 294
     </address>
295 295
     <address type='replyroom' jid='jdev@conference.jabber.org'/>
296 296
   </addresses>
297
-</message>]]></example>      
297
+</message>]]></example>
298 298
         </section2>
299 299
     </section1>
300 300
 
@@ -325,19 +325,19 @@
325 325
         service also receive the associated unavailable presence.</p>
326 326
       </section2>
327 327
     </section1>
328
-    
328
+
329 329
     <section1 topic='Multicast Usage' anchor='multicast'>
330 330
         <p>The following usage scenario shows how messages flow through both address-enabled and non-address-enabled portions of the Jabber network.</p>
331
-    
331
+
332 332
         <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>
333 333
 
334 334
         <ol>
335 335
             <li>User desires to send a stanza to more than one
336 336
             recipient.</li>
337
-      
337
+
338 338
             <li>Client determines the JID of a multicast service,
339 339
             using Service Discovery.</li>
340
-      
340
+
341 341
             <li>If no multicast service is found, the client MAY
342 342
             choose to deliver each stanza individually, or it MAY
343 343
             query each of the servers associated with desired
@@ -346,8 +346,8 @@
346 346
 
347 347
             <li>If a multicast service is found, the client constructs
348 348
             a stanza with an address block, and sends it to the
349
-            multicast service. (Note: For the following rules, any 
350
-            address that was marked on the incoming address header 
349
+            multicast service. (Note: For the following rules, any
350
+            address that was marked on the incoming address header
351 351
             with delivered='true' is never re-delivered.)</li>
352 352
 
353 353
             <li>The server checks to see if it can deliver to all of
@@ -372,12 +372,12 @@
372 372
             in the original address header, the local server determines
373 373
             whether the target server supports multicast, using Service
374 374
             Discovery.</li>
375
-      
375
+
376 376
             <li>If the target server does not support address headers, the
377 377
             local server sends a copy of the stanza to each address,
378 378
             with the 'to' attribute on the outer stanza set to the JID
379 379
             of the given addressee.</li>
380
-      
380
+
381 381
             <li>If the target server does support address headers, the server
382 382
             removes the delivered='true' attributes on each of the
383 383
             addresses bound for that server, and replaces the 'to'
@@ -586,7 +586,7 @@
586 586
 
587 587
         <ol>
588 588
             <li>If a noreply address is
589
-            specified, a reply SHOULD NOT be generated.</li> 
589
+            specified, a reply SHOULD NOT be generated.</li>
590 590
 
591 591
             <li>If one or more replyroom addresses are specified, the client SHOULD
592 592
             join the specified chat rooms instead of replying directly

+ 2
- 2
xep-0034.xml View File

@@ -71,7 +71,7 @@
71 71
 
72 72
 <section1 topic='Introduction'>
73 73
   <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>
74
-  
74
+
75 75
   <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>
76 76
 
77 77
   <p>The reader is expected to have read and understood the SASL specification before reading this document.</p>
@@ -102,7 +102,7 @@
102 102
     </ol>
103 103
 
104 104
     <p>After authentication has completed, the client sends a packet to begin the session.</p>
105
-    
105
+
106 106
     <p>The namespace identifier for this protocol is http://www.iana.org/assignments/sasl-mechanisms.</p>
107 107
 
108 108
     <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;
122 122
   <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>
123 123
 
124 124
   <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>
125
-  
125
+
126 126
   <p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
127 127
 </section1>
128 128
 

+ 1
- 1
xep-0036.xml View File

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

+ 40
- 40
xep-0037.xml View File

@@ -107,9 +107,9 @@
107 107
 &lt;iq
108 108
   id='dsps1'
109 109
   type='get'
110
-  from='rob@nauseum.org/dspsclient' 
110
+  from='rob@nauseum.org/dspsclient'
111 111
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a44'&gt;
112
-  &lt;query type='create' 
112
+  &lt;query type='create'
113 113
     xmlns='jabber:iq:dsps'
114 114
     minthroughput='1.5KB'
115 115
     maxpublic='20'&gt;
@@ -146,9 +146,9 @@
146 146
 
147 147
 <example>
148 148
 &lt;iq
149
-  id='dsps1' 
149
+  id='dsps1'
150 150
   type='result'
151
-  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
151
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
152 152
   to='rob@nauseum.org/dspsclient'&gt;
153 153
   &lt;query type='create' xmlns='jabber:iq:dsps'
154 154
     wait='10'
@@ -248,7 +248,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
248 248
     <section3 topic='Connecting to DSPS via SSL method {optional}'>
249 249
 
250 250
       <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>
251
-      
251
+
252 252
 <example>starttls&lt;CR&gt;</example>
253 253
 
254 254
       <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;
335 335
         <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>
336 336
         <li><strong>&quot;status&quot;</strong> is new status of peer.</li>
337 337
       </ul>
338
-                                                    
338
+
339 339
       <p>Possible failure messages:</p>
340 340
 
341 341
 
@@ -346,7 +346,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
346 346
       </table>
347 347
 
348 348
     </section3>
349
-    
349
+
350 350
   </section2>
351 351
 
352 352
   <section2 topic='Stream administration'>
@@ -361,9 +361,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
361 361
 
362 362
 <example>
363 363
 &lt;iq
364
-  id='dsps3' 
364
+  id='dsps3'
365 365
   type='set'
366
-  from='rob@nauseum.org/dspsclient' 
366
+  from='rob@nauseum.org/dspsclient'
367 367
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
368 368
   &lt;query type='admin' xmlns='jabber:iq:dsps' expire='20' wait='10'&gt;
369 369
     &lt;comment&gt;welcome to the stream&lt;/comment&gt;
@@ -410,18 +410,18 @@ Content-Type: application/octet-stream&lt;CR&gt;
410 410
       <tr><th>Code</th><th>Message</th><th>Description</th></tr>
411 411
       <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>
412 412
     </table>
413
-                                
413
+
414 414
     <section3 topic='Invitation to stream {optional}'>
415 415
 
416 416
       <p>Upon invite DSPS will attempt to invite each of the peers like so:</p>
417 417
 
418 418
 <example>
419 419
 &lt;iq
420
-  id='dsps4' 
420
+  id='dsps4'
421 421
   type='get'
422
-  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
422
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
423 423
   to='foo@bar.com/resource'&gt;
424
-  &lt;query type='acknowledge' 
424
+  &lt;query type='acknowledge'
425 425
     xmlns='jabber:iq:dsps'
426 426
     status='master'
427 427
     expire='20'&gt;
@@ -447,9 +447,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
447 447
       <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>
448 448
 
449 449
 <example>
450
-&lt;iq 
450
+&lt;iq
451 451
   id='dsps5'
452
-  type='set' 
452
+  type='set'
453 453
   from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
454 454
   to='foo@bar.com/resource'&gt;
455 455
   &lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'&gt;
@@ -469,9 +469,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
469 469
 
470 470
 <example>
471 471
 &lt;iq
472
-  id='dsps6' 
472
+  id='dsps6'
473 473
   type='set'
474
-  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
474
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
475 475
   to='foo@bar.com/resource'&gt;
476 476
   &lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
477 477
     &lt;peer status='drop'&gt;JID&lt;/peer&gt;
@@ -487,22 +487,22 @@ Content-Type: application/octet-stream&lt;CR&gt;
487 487
       </ul>
488 488
 
489 489
     </section3>
490
-    
490
+
491 491
   </section2>
492 492
 
493 493
   <section2 topic='Invitation reply'>
494 494
 
495 495
     <p>An invited peer has the option to accept or reject an invitation to a stream.</p>
496
-    
496
+
497 497
     <section3 topic='Accepting an invite'>
498 498
 
499 499
       <p>To accept an invitation to a stream, the peer must reply like so:</p>
500 500
 
501 501
 <example>
502 502
 &lt;iq
503
-  id='dsps4' 
503
+  id='dsps4'
504 504
   type='result'
505
-  from='foo@bar.com/moredsps' 
505
+  from='foo@bar.com/moredsps'
506 506
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
507 507
   &lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='connect'/&gt;
508 508
 &lt;/iq&gt;
@@ -518,16 +518,16 @@ Content-Type: application/octet-stream&lt;CR&gt;
518 518
       <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>
519 519
 
520 520
     </section3>
521
-    
521
+
522 522
     <section3 topic='Rejecting an invite'>
523 523
 
524 524
      <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>
525 525
 
526 526
 <example>
527 527
 &lt;iq
528
-  id='dsps4' 
528
+  id='dsps4'
529 529
   type='result'
530
-  from='foo@bar.com/moredsps' 
530
+  from='foo@bar.com/moredsps'
531 531
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
532 532
   &lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'/&gt;
533 533
 &lt;/iq&gt;
@@ -539,10 +539,10 @@ Content-Type: application/octet-stream&lt;CR&gt;
539 539
         <li><strong>&quot;status&quot;</strong> drop denotes an rejection of invitation.</li>
540 540
       </ul>
541 541
 
542
-      <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> 
542
+      <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>
543 543
 
544 544
     </section3>
545
-    
545
+
546 546
   </section2>
547 547
 
548 548
   <section2 topic='Disconnection handling'>
@@ -554,9 +554,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
554 554
     <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>
555 555
 
556 556
 <example>
557
-&lt;iq 
557
+&lt;iq
558 558
   id='dsps7'
559
-  type='set' 
559
+  type='set'
560 560
   from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
561 561
   to='foo@bar.com/resource'&gt;
562 562
   &lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
@@ -620,9 +620,9 @@ this is the data in ASCII form
620 620
 
621 621
 <example>
622 622
 &lt;iq
623
-  id='dsps8' 
623
+  id='dsps8'
624 624
   type='get'
625
-  from='rob@nauseum.org/dspsclient' 
625
+  from='rob@nauseum.org/dspsclient'
626 626
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
627 627
   &lt;query type='who' xmlns='jabber:iq:dsps'/&gt;
628 628
 &lt;/iq&gt;
@@ -638,13 +638,13 @@ this is the data in ASCII form
638 638
       <p>The query reply is formatted like so:</p>
639 639
 
640 640
 <example>
641
-&lt;iq 
641
+&lt;iq
642 642
   id='dsps8'
643
-  type='result' 
643
+  type='result'
644 644
   from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
645 645
   to='rob@nauseum.org/dspsclient'&gt;
646 646
   &lt;query type='who' xmlns='jabber:iq:dsps'&gt;
647
-    &lt;peer 
647
+    &lt;peer
648 648
       type='master'
649 649
       id='0'
650 650
       status='connect'
@@ -671,9 +671,9 @@ this is the data in ASCII form
671 671
       <p>To retrieve listing of all stream configuration/statistics values or public streams, any registered peer sends a message like so:</p>
672 672
 
673 673
 <example>
674
-&lt;iq 
674
+&lt;iq
675 675
   id='dsps9'
676
-  type='get' 
676
+  type='get'
677 677
   from='rob@nauseum.org/dspsclient'
678 678
   to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
679 679
   &lt;query type='stats' xmlns='jabber:iq:dsps'/&gt;
@@ -689,9 +689,9 @@ this is the data in ASCII form
689 689
 
690 690
 <example>
691 691
 &lt;iq
692
-  id='dsps9' 
692
+  id='dsps9'
693 693
   type='result'
694
-  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33' 
694
+  from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
695 695
   to='rob@nauseum.org/dspsclient'&gt;
696 696
   &lt;query type='stats' xmlns='jabber:iq:dsps'
697 697
     init='00000000000000'
@@ -736,12 +736,12 @@ this is the data in ASCII form
736 736
       <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>
737 737
 
738 738
     </section3>
739
-    
739
+
740 740
   </section2>
741 741
 
742 742
   <section2 topic='Stream shutdown'>
743 743
 
744
-    <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> 
744
+    <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>
745 745
 
746 746
     <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>
747 747
 
@@ -749,7 +749,7 @@ this is the data in ASCII form
749 749
 
750 750
   <section2 topic='Error message format'>
751 751
 
752
-    <p>Error messages look like so:</p>  
752
+    <p>Error messages look like so:</p>
753 753
 
754 754
 <example>
755 755
 &lt;iq

+ 16
- 16
xep-0040.xml View File

@@ -74,7 +74,7 @@
74 74
          <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>
75 75
          <p>Sequence numbers will be sent in each publish thus:</p>
76 76
          <example>
77
-&lt;iq type="set" 
77
+&lt;iq type="set"
78 78
     to="myclient@server.net"
79 79
     from="pubsub.localhost"&gt;
80 80
   &lt;query xmlns="jabber:iq:pubsub"&gt;
@@ -96,7 +96,7 @@
96 96
          <p>The operation of LINK and SOURCE sequence numbers are described below.</p>
97 97
       </section2>
98 98
       <section2 topic="Link Level Swquence Numbering">
99
-         <p>This will concern itself with data sent on each channel. A 
99
+         <p>This will concern itself with data sent on each channel. A
100 100
 channel can be, but is not limited to the following:</p>
101 101
          <ul>
102 102
            <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>
116 116
       <section2 topic="Gap Filling">
117 117
          <p>When a subscriber detects a gap on its link, it can request for the data to be resent thus:</p>
118 118
          <example>
119
-&lt;iq 
120
-    type="get" 
119
+&lt;iq
120
+    type="get"
121 121
     id="plugthegap1"
122 122
     from="myclient@server.net"
123 123
     to="pubsub.localhost"&gt;
@@ -130,8 +130,8 @@ channel can be, but is not limited to the following:</p>
130 130
          <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>
131 131
          <p>All is not lost. The subscriber has a last-ditch repair scenario by sending last-received source sequence numbers. </p>
132 132
          <example>
133
-&lt;iq 
134
-    type="get" 
133
+&lt;iq
134
+    type="get"
135 135
     id="plugthegap1"
136 136
     from="myclient@server.net"
137 137
     to="pubsub.localhost"&gt;
@@ -144,18 +144,18 @@ channel can be, but is not limited to the following:</p>
144 144
          <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>
145 145
          <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>
146 146
          <example>
147
-&lt;iq 
147
+&lt;iq
148 148
     type="set"
149 149
     to="myclient@server.net"
150 150
     from="pubsub.localhost"&gt;
151 151
 &lt;query xmlns="jabber:iq:pubsub"&gt;
152
-    &lt;publish 
152
+    &lt;publish
153 153
         ns="data topics"
154 154
         linkseq="0"
155 155
         sourceseq="7547392"
156 156
         from="publisher.fromaplace"&gt;
157 157
     &lt;/publish&gt;
158
-    &lt;publish 
158
+    &lt;publish
159 159
         ns="data topics"
160 160
         linkseq="1"
161 161
         sourceseq="44211"
@@ -168,12 +168,12 @@ channel can be, but is not limited to the following:</p>
168 168
       <section2 topic="Heartbeats">
169 169
          <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>
170 170
          <example>
171
-&lt;iq 
171
+&lt;iq
172 172
     type="set"
173 173
     to="myclient@server.net"
174 174
     from="pubsub.localhost"&gt;
175 175
   &lt;query xmlns="jabber:iq:pubsub"&gt;
176
-    &lt;publish 
176
+    &lt;publish
177 177
         ns="link.heartbeat"
178 178
         linkseq="57374"
179 179
         from="pubsub.localhost"&gt;
@@ -189,19 +189,19 @@ channel can be, but is not limited to the following:</p>
189 189
       <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>
190 190
       <p>To resolve this a type field may be added to the &lt;publish/&gt; tag.</p>
191 191
       <example>
192
-&lt;iq 
192
+&lt;iq
193 193
     type="set"
194 194
     to="myclient@server.net"
195 195
     from="pubsub.localhost"&gt;
196 196
 &lt;query xmlns="jabber:iq:pubsub"&gt;
197
-    &lt;publish 
197
+    &lt;publish
198 198
         ns="data topics"
199 199
         linkseq="57372"
200 200
         sourceseq="7547392"
201 201
         from="publisher.fromaplace"
202 202
         type="update"&gt;
203 203
     &lt;/publish&gt;
204
-    &lt;publish 
204
+    &lt;publish
205 205
         ns="data topics"
206 206
         linkseq="57373"
207 207
         sourceseq="44211"
@@ -242,12 +242,12 @@ channel can be, but is not limited to the following:</p>
242 242
          <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>
243 243
          <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>
244 244
          <example>
245
-&lt;iq 
245
+&lt;iq
246 246
     type="set"
247 247
     to="myclient@server.net"
248 248
     from="pubsub.localhost"&gt;
249 249
   &lt;query xmlns="jabber:iq:pubsub"&gt;
250
-    &lt;publish 
250
+    &lt;publish
251 251
         ns="data topics"
252 252
         type="update"
253 253
         permtoken="6747"

+ 61
- 61
xep-0042.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Jabber OOB Broadcast Service (JOBS)</title>
10
-  <abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract> 
10
+  <abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0042</number>
13 13
   <status>Retracted</status>
@@ -72,7 +72,7 @@
72 72
     <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>
73 73
 
74 74
     <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>
75
-    
75
+
76 76
     <table caption='Terms in Use'>
77 77
       <tr>
78 78
         <th>Term</th>
@@ -136,12 +136,12 @@
136 136
   </section2>
137 137
   <section2 topic='Creating a Session'>
138 138
     <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>
139
-    
139
+
140 140
     <p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
141
-    
141
+
142 142
     <section3 topic='Simple'>
143 143
       <p>The simplest create request is:</p>
144
-    
144
+
145 145
       <example caption='Creation request'><![CDATA[
146 146
 <iq type='set' from='sender@domain/res' to='jobs.domain' id='JOBS1'>
147 147
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -149,27 +149,27 @@
149 149
 </iq>
150 150
       ]]></example>
151 151
       <example caption='Creation result'><![CDATA[
152
-<iq 
152
+<iq
153 153
     type='result' to='sender@domain/res' from='jobs.domain'>
154 154
   <session xmlns='http://jabber.org/protocol/jobs'
155 155
       status='pending'
156
-      host='jobs.domain' 
156
+      host='jobs.domain'
157 157
       id='01234567'
158
-      port='12676' 
158
+      port='12676'
159 159
       sender='sender@domain/res'
160 160
       buffer='0'
161
-      expires='30' 
161
+      expires='30'
162 162
       receivers='1'/>
163 163
 </iq>
164 164
       ]]></example>
165
-    
165
+
166 166
       <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>
167 167
     </section3>
168 168
     <section3 topic='With Parameters'>
169 169
       <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>
170
-      
170
+
171 171
       <p>To determine the limits, the sender sends an "iq-get" with a &lt;session action="create"/&gt;:</p>
172
-      
172
+
173 173
       <example caption='Parameter statistics request'><![CDATA[
174 174
 <iq id='JOBS0' type='get' to='jobs.domain'>
175 175
   <session xmlns='http://jabber.org/protocol/jobs' action='create'/>
@@ -202,7 +202,7 @@
202 202
       ]]></example>
203 203
 
204 204
       <p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p>
205
-      
205
+
206 206
       <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>
207 207
       <example caption='Creation request, with parameters'><![CDATA[
208 208
 <iq id='JOBS1' type='set' to='jobs.domain'>
@@ -214,25 +214,25 @@
214 214
 <iq type='result' to='sender@domain/res' from='jobs.domain'>
215 215
   <session xmlns='http://jabber.org/protocol/jobs'
216 216
       status='pending'
217
-      host='jobs.domain' 
217
+      host='jobs.domain'
218 218
       id='01234567'
219
-      port='12676' 
219
+      port='12676'
220 220
       sender='sender@domain/res'
221 221
       buffer='0'
222
-      expires='-1' 
222
+      expires='-1'
223 223
       receivers='1'/>
224 224
 </iq>
225 225
       ]]></example>
226
-    
226
+
227 227
       <p>The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.</p>
228
-      
228
+
229 229
       <p>Any parameters that exceed the minimums/maximums causes an error.</p>
230 230
     </section3>
231 231
     <section3 topic='Form-based'>
232 232
       <p>In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a &xep0004; form can be embedded in the &lt;session/&gt;.</p>
233
-      
233
+
234 234
       <p>To create a session using forms, send a &lt;session action="create"/&gt; with an embedded &lt;x xmlns="jabber:x:data"/&gt;:</p>
235
-      
235
+
236 236
       <example caption='Creation form request'><![CDATA[
237 237
 <iq type='get' to='jobs.domain'>
238 238
   <session xmlns='http://jabber.org/protocol/jobs' action='create'>
@@ -243,10 +243,10 @@
243 243
       <example caption='Creation form result'><![CDATA[
244 244
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
245 245
   <session xmlns='http://jabber.org/protocol/jobs'
246
-      host='jobs.domain' 
247
-      port='12676' 
246
+      host='jobs.domain'
247
+      port='12676'
248 248
       buffer='0'
249
-      expires='-1' 
249
+      expires='-1'
250 250
       receivers='1'>
251 251
     <x xmlns='jabber:x:data' type='form'>
252 252
       <instructions>Please specify values for the given fields.</instructions>
@@ -260,10 +260,10 @@
260 260
   </session>
261 261
 </iq>
262 262
       ]]></example>
263
-      
263
+
264 264
       <p>The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the &lt;session/&gt; attributes.</p>
265 265
       <p>Using the form-based approach, the session is then created by sending a &lt;session action='create'/&gt; with a form submission (as defined for "jabber:x:data"):</p>
266
-      
266
+
267 267
       <example caption='Creation request (form-based)'><![CDATA[
268 268
 <iq type='set' to='jobs.domain'>
269 269
   <session xmlns='http://jabber.org/protocol/jobs' action='create'>
@@ -280,12 +280,12 @@
280 280
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
281 281
   <session xmlns='http://jabber.org/protocol/jobs'
282 282
       status='pending'
283
-      host='jobs.domain' 
283
+      host='jobs.domain'
284 284
       id='01234567'
285
-      port='12676' 
285
+      port='12676'
286 286
       sender='sender@domain/res'
287 287
       buffer='0'
288
-      expires='300' 
288
+      expires='300'
289 289
       receivers='1'/>
290 290
 </iq>
291 291
       ]]></example>
@@ -293,7 +293,7 @@
293 293
   </section2>
294 294
   <section2 topic='Inviting Receivers'>
295 295
     <p>Once the session is created, the sender invites receivers to connect. The sender can invite receivers either directly, or via the JOBS service. Most invitations are distributed via &lt;message/&gt;.</p>
296
-    
296
+
297 297
     <section3 topic='Inviting Directly'>
298 298
       <p>The sender can invite receivers directly. This is done using a &lt;message/&gt;:</p>
299 299
       <example caption='Invitation message (direct)'><![CDATA[
@@ -309,7 +309,7 @@
309 309
       receivers='1'/>
310 310
 </message>
311 311
       ]]></example>
312
-      
312
+
313 313
       <p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p>
314 314
       <ul>
315 315
         <li>host</li>
@@ -414,26 +414,26 @@
414 414
   <section2 topic='Connecting OOB'>
415 415
     <section3 topic='Initiating and Authenticating'>
416 416
       <p>When a client connects (sender or receivers), a client-initiated handshake takes place. The purpose of this handshake is to authenticate the OOB connection, in relation to the client's JID. This authentication utilizes both in-band and OOB packets.</p>
417
-    
417
+
418 418
       <p>To start the handshake, the client sends an "init" packet on its established connection:</p>
419
-      
419
+
420 420
       <example caption='Client INIT'><![CDATA[
421 421
 jobs/0.4 init
422 422
 session-id: 01234567
423 423
 client-jid: sender@domain/res
424 424
 
425 425
       ]]></example>
426
-      
426
+
427 427
       <p>If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:</p>
428
-      
428
+
429 429
       <example caption='Server AUTH-CHALLENGE'><![CDATA[
430 430
 jobs/0.4 auth-challenge
431 431
 confirm: SID00001234
432 432
 
433 433
       ]]></example>
434
-      
434
+
435 435
       <p>Once received, the client then sends an "iq-set" containing a &lt;session action="authenticate"/&gt;, which itself contains an &lt;item type='auth' action='confirm'/&gt; with this confirm key:</p>
436
-      
436
+
437 437
       <example caption='Authentication request (from Client)'><![CDATA[
438 438
   <iq type='set' to='jobs.domain'>
439 439
     <session xmlns='http://jabber.org/protocol/jobs'
@@ -443,9 +443,9 @@ confirm: SID00001234
443 443
     </session>
444 444
   </iq>hehe
445 445
       ]]></example>
446
-    
446
+
447 447
       <p>The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a &lt;session action="authenticate"/&gt; containing a &lt;item type="auth" action="accept"/&gt; with the accept key:</p>
448
-    
448
+
449 449
       <example caption='Authentication result (from Server)'><![CDATA[
450 450
   <iq type='result' from='jobs.domain' to='sender@domain/res'>
451 451
     <session xmlns='http://jabber.org/protocol/jobs'
@@ -456,17 +456,17 @@ confirm: SID00001234
456 456
     </session>
457 457
   </iq>
458 458
     ]]></example>
459
-    
459
+
460 460
       <p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p>
461
-    
461
+
462 462
       <example caption='Client AUTH-RESPONSE'><![CDATA[
463 463
   jobs/0.4 auth-response
464 464
   accept: SID88884321
465
-  
465
+
466 466
     ]]></example>
467
-    
467
+
468 468
       <p>If the connection is accepted, the JOBS service sends a "connected" packet:</p>
469
-    
469
+
470 470
       <example caption='Server CONNECTED'><![CDATA[
471 471
   jobs/0.4 connected
472 472
 
@@ -475,9 +475,9 @@ confirm: SID00001234
475 475
     </section3>
476 476
     <section3 topic='Authorizing'>
477 477
       <p>Authenticating ensures the OOB connection matches a particular JID. Authorizing ensures to the service that receiver is allowed to be connected to the session. To determine if the session connection should be accepted or rejected, the JOBS service first checks if the JID matches the sender. This matches against the "full" JID, including node, domain, and resource. If this connection is the sender, it is allowed. Otherwise, the service confirms the connection with the sender.</p>
478
-      
478
+
479 479
       <p>If a confirmation is required, the service sends an "iq-get" to the sender, with a &lt;session action="authorize"/&gt; containing an &lt;item type"connection" action="confirm"/&gt; with the full JID of the receiver:</p>
480
-      
480
+
481 481
       <example caption='Confirmation request'><![CDATA[
482 482
 <iq type='get' to='sender@domain/res' id='JOBS5' from='jobs.domain'>
483 483
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -509,12 +509,12 @@ confirm: SID00001234
509 509
   </session>
510 510
 </iq>
511 511
       ]]></example>
512
-      
512
+
513 513
       <p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p>
514 514
     </section3>
515 515
     <section3 topic='Dropping'>
516 516
       <p>The sender may drop a connection at any time. To drop a connection, the sender sends an "iq-set" with the &lt;session/&gt; containing the "connection" to drop:</p>
517
-      
517
+
518 518
       <example caption='Drop request'><![CDATA[
519 519
 <iq type='set' to='jobs.domain'>
520 520
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -524,9 +524,9 @@ confirm: SID00001234
524 524
   </session>
525 525
 </iq>
526 526
       ]]></example>
527
-      
527
+
528 528
       <p>If the connection is successfully dropped, the service returns an "iq-result":</p>
529
-      
529
+
530 530
       <example caption='Drop result'><![CDATA[
531 531
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
532 532
   <session  xmlns='http://jabber.org/protocol/jobs'
@@ -534,20 +534,20 @@ confirm: SID00001234
534 534
       id='01234567'/>
535 535
 </iq>
536 536
       ]]></example>
537
-      
537
+
538 538
       <p>The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).</p>
539 539
     </section3>
540 540
   </section2>
541 541
   <section2 topic='Deleting a Session'>
542 542
     <p>Sessions are deleted either by timeout or explicitly. Sessions are deleted by timeout automatically under certain conditions. Sessions can also be deleted explicity by their senders, at any time. Regardless of the method of deletion, a notice is sent to all connected.</p>
543
-    
543
+
544 544
     <p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
545 545
     <section3 topic='Expiring'>
546 546
       <p>The exact conditions that expire a session are mostly up to the implementation. At a minimum, a session SHOULD be expired when there are less than two connections, and the "expires" time is reached.</p>
547 547
     </section3>
548 548
     <section3 topic='Deleting Explicitly'>
549 549
       <p>To explictly delete a session, the sender sends an "iq-set" containing a &lt;session action="delete"/&gt;:</p>
550
-  
550
+
551 551
       <example caption='Delete request'><![CDATA[
552 552
 <iq id='JOBS50' type='set' to='jobs.domain'>
553 553
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -566,7 +566,7 @@ confirm: SID00001234
566 566
   <section2 topic='Being Notified about Events'>
567 567
     <section3 topic='Connection Accepted'>
568 568
       <p>When a connection is accepted, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='accept'/&gt;:</p>
569
-      
569
+
570 570
       <example caption='"Connection Accepted" message'><![CDATA[
571 571
 <message to='sender@domain/res' from='jobs.domain'>
572 572
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -577,12 +577,12 @@ confirm: SID00001234
577 577
   </session>
578 578
 </message>
579 579
       ]]></example>
580
-      
580
+
581 581
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
582 582
     </section3>
583 583
     <section3 topic='Connection Rejected'>
584 584
       <p>When a connection is rejected, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='reject'/&gt;:</p>
585
-      
585
+
586 586
       <example caption='"Connection Rejected" message'><![CDATA[
587 587
 <message to='receiver@domain/res' from='jobs.domain'>
588 588
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -593,12 +593,12 @@ confirm: SID00001234
593 593
   </session>
594 594
 </message>
595 595
       ]]></example>
596
-      
596
+
597 597
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
598 598
     </section3>
599 599
     <section3 topic='Connection Dropped'>
600 600
       <p>When a connection is dropped, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='drop'/&gt;:</p>
601
-      
601
+
602 602
       <example caption='"Connection Dropped" message'><![CDATA[
603 603
 <message to='receiver@domain/res' from='jobs.domain'>
604 604
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -609,12 +609,12 @@ confirm: SID00001234
609 609
   </session>
610 610
 </message>
611 611
       ]]></example>
612
-      
612
+
613 613
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
614 614
     </section3>
615 615
     <section3 topic='Session Deleted'>
616 616
       <p>When a session is deleted, any clients connected to the session are immediately disconnected. The "notify" message is sent to the sender and any receivers still connected, with the &lt;session action="notify"/&gt; containing an &lt;item type="status"/&gt;:</p>
617
-      
617
+
618 618
       <example caption='"Session Deleted (explicitly)" message'><![CDATA[
619 619
 <message to='sender@domain/res' from='jobs.domain'>
620 620
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -636,7 +636,7 @@ confirm: SID00001234
636 636
   </session>
637 637
 </message>
638 638
       ]]></example>
639
-      
639
+
640 640
       <p>The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.</p>
641 641
     </section3>
642 642
   </section2>
@@ -922,7 +922,7 @@ confirm: SID00001234
922 922
           <td>The JOBS service cannot accept any additional sessions at this time. Future requests may be accepted.</td>
923 923
         </tr>
924 924
       </table>
925
-  
925
+
926 926
       <table caption='&lt;session action="delete"/&gt; errors'>
927 927
         <tr>
928 928
           <th>Code</th>

+ 166
- 166
xep-0043.xml View File

@@ -40,7 +40,7 @@
40 40
     <p>Accessing a RDBMS in a generic fashion is a complex and difficult
41 41
     task. Consequently, this will not be an attempt to XMLize a generic
42 42
     Database API or query language. Instead, it will providing a
43
-    simple mechanism for a JID to read/write data that it has access to 
43
+    simple mechanism for a JID to read/write data that it has access to
44 44
     and specifying a model for those schemas to use in xml.</p>
45 45
     <p>This document has two aims.</p>
46 46
     <ol>
@@ -48,8 +48,8 @@
48 48
       <li>Perform near SQL-like data manipulation</li>
49 49
     </ol>
50 50
     <p>Although designed for use with an RDBMS this document is not
51
-    restricted to such uses. It may be used with any data storage 
52
-    system that can be broken down to a simple table, column/row 
51
+    restricted to such uses. It may be used with any data storage
52
+    system that can be broken down to a simple table, column/row
53 53
     format. for example comma delimited files.</p>
54 54
   </section1>
55 55
   <section1 topic='Prerequisites'>
@@ -57,9 +57,9 @@
57 57
     must be aware of the following.</p>
58 58
 
59 59
     <section2 topic='Namespace'>
60
-      <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link> 
60
+      <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
61 61
       will be used until this becomes a jep. Once officially accepted as
62
-      a jep and approved as final by the council, it will become 
62
+      a jep and approved as final by the council, it will become
63 63
       <link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
64 64
     </section2>
65 65
     <section2 topic='Elements'>
@@ -132,45 +132,45 @@
132 132
 &lt;/database&gt;
133 133
       </code>
134 134
 
135
-      <p>All examples will assume the existence of the following rdbms setup. A 
135
+      <p>All examples will assume the existence of the following rdbms setup. A
136 136
       database named 'testdb' with tables created with following SQL
137 137
       script:</p>
138
-  
138
+
139 139
       <code>
140
-        create table tbl_one 
141
-        ( 
142
-          a_int int, 
143
-          a_float float, 
144
-          a_char  char(10)  
140
+        create table tbl_one
141
+        (
142
+          a_int int,
143
+          a_float float,
144
+          a_char  c