Browse Source

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

sed -i 's/^\s\+]]>/]]>/g' xep-*.xml
Emmanuel Gil Peyrot 2 years ago
parent
commit
7a64b7b1ed
100 changed files with 1370 additions and 1370 deletions
  1. 1
    1
      xep-0001.xml
  2. 15
    15
      xep-0003.xml
  3. 13
    13
      xep-0004.xml
  4. 6
    6
      xep-0009.xml
  5. 1
    1
      xep-0011.xml
  6. 14
    14
      xep-0012.xml
  7. 17
    17
      xep-0013.xml
  8. 56
    56
      xep-0016.xml
  9. 6
    6
      xep-0020.xml
  10. 13
    13
      xep-0022.xml
  11. 1
    1
      xep-0023.xml
  12. 2
    2
      xep-0027.xml
  13. 34
    34
      xep-0030.xml
  14. 1
    1
      xep-0033.xml
  15. 2
    2
      xep-0038.xml
  16. 1
    1
      xep-0041.xml
  17. 39
    39
      xep-0042.xml
  18. 12
    12
      xep-0047.xml
  19. 8
    8
      xep-0048.xml
  20. 6
    6
      xep-0049.xml
  21. 28
    28
      xep-0050.xml
  22. 4
    4
      xep-0051.xml
  23. 1
    1
      xep-0052.xml
  24. 16
    16
      xep-0054.xml
  25. 12
    12
      xep-0055.xml
  26. 22
    22
      xep-0059.xml
  27. 13
    13
      xep-0060.xml
  28. 1
    1
      xep-0061.xml
  29. 39
    39
      xep-0065.xml
  30. 13
    13
      xep-0066.xml
  31. 8
    8
      xep-0068.xml
  32. 13
    13
      xep-0070.xml
  33. 14
    14
      xep-0071.xml
  34. 18
    18
      xep-0072.xml
  35. 7
    7
      xep-0074.xml
  36. 9
    9
      xep-0075.xml
  37. 5
    5
      xep-0076.xml
  38. 41
    41
      xep-0077.xml
  39. 11
    11
      xep-0078.xml
  40. 33
    33
      xep-0079.xml
  41. 5
    5
      xep-0080.xml
  42. 11
    11
      xep-0081.xml
  43. 3
    3
      xep-0083.xml
  44. 18
    18
      xep-0084.xml
  45. 22
    22
      xep-0085.xml
  46. 13
    13
      xep-0087.xml
  47. 3
    3
      xep-0090.xml
  48. 4
    4
      xep-0091.xml
  49. 5
    5
      xep-0092.xml
  50. 2
    2
      xep-0093.xml
  51. 3
    3
      xep-0094.xml
  52. 10
    10
      xep-0095.xml
  53. 17
    17
      xep-0096.xml
  54. 8
    8
      xep-0098.xml
  55. 10
    10
      xep-0099.xml
  56. 56
    56
      xep-0100.xml
  57. 11
    11
      xep-0103.xml
  58. 6
    6
      xep-0104.xml
  59. 5
    5
      xep-0105.xml
  60. 8
    8
      xep-0107.xml
  61. 8
    8
      xep-0108.xml
  62. 8
    8
      xep-0109.xml
  63. 3
    3
      xep-0110.xml
  64. 9
    9
      xep-0111.xml
  65. 4
    4
      xep-0112.xml
  66. 10
    10
      xep-0113.xml
  67. 6
    6
      xep-0114.xml
  68. 15
    15
      xep-0115.xml
  69. 15
    15
      xep-0116.xml
  70. 5
    5
      xep-0118.xml
  71. 8
    8
      xep-0120.xml
  72. 3
    3
      xep-0121.xml
  73. 12
    12
      xep-0122.xml
  74. 4
    4
      xep-0123.xml
  75. 3
    3
      xep-0124.xml
  76. 23
    23
      xep-0126.xml
  77. 3
    3
      xep-0127.xml
  78. 2
    2
      xep-0128.xml
  79. 11
    11
      xep-0129.xml
  80. 38
    38
      xep-0130.xml
  81. 12
    12
      xep-0131.xml
  82. 10
    10
      xep-0132.xml
  83. 111
    111
      xep-0133.xml
  84. 36
    36
      xep-0135.xml
  85. 63
    63
      xep-0136.xml
  86. 13
    13
      xep-0137.xml
  87. 11
    11
      xep-0138.xml
  88. 10
    10
      xep-0140.xml
  89. 5
    5
      xep-0141.xml
  90. 56
    56
      xep-0142.xml
  91. 2
    2
      xep-0143.xml
  92. 6
    6
      xep-0144.xml
  93. 1
    1
      xep-0145.xml
  94. 9
    9
      xep-0146.xml
  95. 17
    17
      xep-0147.xml
  96. 9
    9
      xep-0148.xml
  97. 4
    4
      xep-0149.xml
  98. 18
    18
      xep-0150.xml
  99. 11
    11
      xep-0152.xml
  100. 0
    0
      xep-0153.xml

+ 1
- 1
xep-0001.xml View File

@@ -846,6 +846,6 @@ THE SOFTWARE.
846 846
   </xs:simpleType>
847 847
 
848 848
 </xs:schema>
849
-  ]]></code>
849
+]]></code>
850 850
 </section1>
851 851
 </xep>

+ 15
- 15
xep-0003.xml View File

@@ -90,14 +90,14 @@
90 90
     <expire>600</expire>
91 91
   </query>
92 92
 </iq>
93
-  ]]></example>
93
+]]></example>
94 94
   <example caption='Result from PASS Service'><![CDATA[
95 95
 <iq id='pass1' type='result' from='pass.jabber.org'>
96 96
   <query xmlns='jabber:iq:pass'>
97 97
     <server port='43253'>1.2.3.4</server>
98 98
   </query>
99 99
 </iq>
100
-  ]]></example>
100
+]]></example>
101 101
   <p>At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.</p>
102 102
   <p>The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an &lt;expire/&gt; value (in seconds).  If the service is not configured with an expire value, it will not timeout the connection, and will start listening on the port again after one of the two sides disconnects.</p>
103 103
   <table caption='Error Codes'>
@@ -125,7 +125,7 @@
125 125
     <proxy port='43523'>1.2.3.4</proxy>
126 126
   </query>
127 127
 </iq>
128
-  ]]></example>
128
+]]></example>
129 129
   <example caption='IQ result to accept connection'><![CDATA[
130 130
 <iq type='result'
131 131
     id='pass2'
@@ -133,7 +133,7 @@
133 133
     to='pass.jabber.org'>
134 134
   <query xmlns='jabber:iq:pass'/>
135 135
 </iq>
136
-  ]]></example>
136
+]]></example>
137 137
   <p>The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.</p>
138 138
   <p>Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.</p>
139 139
 </section1>
@@ -152,7 +152,7 @@
152 152
     <proxy port='43253'>1.2.3.4</proxy>
153 153
   </query>
154 154
 </iq>
155
-    ]]></example>
155
+]]></example>
156 156
     <example caption='Acknowledgement of expiration'><![CDATA[
157 157
 <iq type='result'
158 158
     id='pass3'
@@ -160,7 +160,7 @@
160 160
     to='pass.jabber.org'>
161 161
   <query xmlns='jabber:iq:pass'/>
162 162
 </iq>
163
-    ]]></example>
163
+]]></example>
164 164
   </section2>
165 165
   <section2 topic='oneshot'>
166 166
     <p>This tells the server to listen once, and then close the port.  Even if the &lt;expire/&gt; has not been met, the &lt;oneshot/&gt; overrides that and shuts down the listening port.  When this happens the server notifies the client with the following packet:</p>
@@ -175,7 +175,7 @@
175 175
     <proxy port='43253'>1.2.3.4</proxy>
176 176
   </query>
177 177
 </iq>
178
-    ]]></example>
178
+]]></example>
179 179
     <example caption='Client acknowledges closing of oneshot port'><![CDATA[
180 180
 <iq type='result'
181 181
     id='pass4'
@@ -183,7 +183,7 @@
183 183
     to='pass.jabber.org'>
184 184
   <query xmlns='jabber:iq:pass'/>
185 185
 </iq>
186
-    ]]></example>
186
+]]></example>
187 187
   </section2>
188 188
   <section2 topic='close'>
189 189
     <p>This tells the server to explicitly shut down a listening port.  Useful for when the client shuts down and can tell the PASS service to recycle the port. The server sends back:</p>
@@ -197,7 +197,7 @@
197 197
     <proxy port='43253'>1.2.3.4</proxy>
198 198
   </query>
199 199
 </iq>
200
-    ]]></example>
200
+]]></example>
201 201
     <example caption='Server acknowledges port closing request'><![CDATA[
202 202
 <iq type='result'
203 203
     id='pass5'
@@ -205,7 +205,7 @@
205 205
     from='pass.jabber.org'>
206 206
   <query xmlns='jabber:iq:pass'/>
207 207
 </iq>
208
-    ]]></example>
208
+]]></example>
209 209
     <table caption='Error Codes'>
210 210
       <tr>
211 211
         <th>Code</th>
@@ -246,7 +246,7 @@
246 246
     from='you@jabber.org/resource'>
247 247
   <query xmlns='jabber:iq:pass'/>
248 248
 </iq>
249
-    ]]></example>
249
+]]></example>
250 250
     <p>The other client SHOULD send back:</p>
251 251
     <example><![CDATA[
252 252
 <iq type='result'
@@ -257,7 +257,7 @@
257 257
     <client>4.3.2.1</client>
258 258
   </query>
259 259
 </iq>
260
-    ]]></example>
260
+]]></example>
261 261
     <p>Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the &lt;client/&gt; information upon a connection.</p>
262 262
   </section2>
263 263
   <section2 topic='Denying a Connection'>
@@ -273,7 +273,7 @@
273 273
     <proxy port='43523'>1.2.3.4</proxy>
274 274
   </query>
275 275
 </iq>
276
-    ]]></example>
276
+]]></example>
277 277
     <p>Your client would send back:</p>
278 278
     <example><![CDATA[
279 279
 <iq type='error'
@@ -288,7 +288,7 @@
288 288
     <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
289 289
   </error>
290 290
 </iq>
291
-    ]]></example>
291
+]]></example>
292 292
     <table caption='Error Codes'>
293 293
       <tr>
294 294
         <th>Code</th>
@@ -354,6 +354,6 @@
354 354
   </xs:simpleType>
355 355
 
356 356
 </xs:schema>
357
-    ]]></code>
357
+]]></code>
358 358
 </section1>
359 359
 </xep>

+ 13
- 13
xep-0004.xml View File

@@ -169,7 +169,7 @@
169 169
     <option label='option-label'><value>option-value</value></option>
170 170
   </field>
171 171
 </x>
172
-  ]]></code>
172
+]]></code>
173 173
   <p>The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included either directly as a first-level child of a &MESSAGE; stanza or as a second-level child of an &IQ; stanza (where the first-level child is an element qualified by a "wrapper" namespace); see also the restrictions enumerated below.</p>
174 174
   <p>The OPTIONAL &lt;title/&gt; and &lt;instructions/&gt; elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the &lt;instructions/&gt; element MAY be included.</p>
175 175
   <section2 topic='Form Types' anchor='protocol-formtypes'>
@@ -299,7 +299,7 @@
299 299
   .
300 300
   .
301 301
 </x>
302
-    ]]></code>
302
+]]></code>
303 303
     <p>Each of these elements MUST contain one or more &lt;field/&gt; children. The &lt;reported/&gt; element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the &lt;field/&gt; elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a &lt;value/&gt; element. Each &lt;item/&gt; element defines one item in the result set, and MUST contain each field specified in the &lt;reported/&gt; element (although the XML character data of the &lt;value/&gt; element MAY be null).</p>
304 304
   </section2>
305 305
 </section1>
@@ -321,7 +321,7 @@
321 321
            node='create'
322 322
            action='execute'/>
323 323
 </iq>
324
-    ]]></example>
324
+]]></example>
325 325
     <p>The hosting service then returns a data form to the user:</p>
326 326
     <example caption="Service Returns Bot Creation Form"><![CDATA[
327 327
 <iq from='joogle@botster.shakespeare.lit'
@@ -388,7 +388,7 @@
388 388
     </x>
389 389
   </command>
390 390
 </iq>
391
-    ]]></example>
391
+]]></example>
392 392
     <p>The user then submits the configuration form:</p>
393 393
     <example caption="User Submits Bot Creation Form"><![CDATA[
394 394
 <iq from='romeo@montague.net/home'
@@ -432,7 +432,7 @@
432 432
     </x>
433 433
   </command>
434 434
 </iq>
435
-    ]]></example>
435
+]]></example>
436 436
     <p>The service then returns the results to the user:</p>
437 437
     <example caption="Service Returns Bot Creation Result"><![CDATA[
438 438
 <iq from='joogle@botster.shakespeare.lit'
@@ -471,7 +471,7 @@
471 471
     </x>
472 472
   </command>
473 473
 </iq>
474
-    ]]></example>
474
+]]></example>
475 475
   </section2>
476 476
   <section2 topic='Search' anchor='examples-search'>
477 477
     <p>Now that the user has created this search bot, let us suppose that one of the friends he has invited decides to try it out by sending a search request:</p>
@@ -485,7 +485,7 @@
485 485
            node='search'
486 486
            action='execute'/>
487 487
 </iq>
488
-    ]]></example>
488
+]]></example>
489 489
     <example caption="Service Returns Search Form"><![CDATA[
490 490
 <iq from='joogle@botster.shakespeare.lit'
491 491
     to='juliet@capulet.com/chamber'
@@ -505,7 +505,7 @@
505 505
     </x>
506 506
   </command>
507 507
 </iq>
508
-    ]]></example>
508
+]]></example>
509 509
     <example caption="User Submits Search Form"><![CDATA[
510 510
 <iq from='juliet@capulet.com/chamber'
511 511
     to='joogle@botster.shakespeare.lit'
@@ -521,7 +521,7 @@
521 521
     </x>
522 522
   </command>
523 523
 </iq>
524
-    ]]></example>
524
+]]></example>
525 525
     <example caption="Service Returns Search Results"><![CDATA[
526 526
 <iq from='joogle@botster.shakespeare.lit'
527 527
     to='juliet@capulet.com/chamber'
@@ -580,7 +580,7 @@
580 580
     </x>
581 581
   </command>
582 582
 </iq>
583
-    ]]></example>
583
+]]></example>
584 584
   </section2>
585 585
 </section1>
586 586
 <section1 topic='Service Discovery' anchor='disco'>
@@ -592,7 +592,7 @@
592 592
     id='disco1'>
593 593
   <query xmlns='http://jabber.org/protocol/disco#info'/>
594 594
 </iq>
595
-  ]]></example>
595
+]]></example>
596 596
   <example caption="Service Discovery information response"><![CDATA[
597 597
 <iq type='result'
598 598
     from='juliet@capulet.com/balcony'
@@ -604,7 +604,7 @@
604 604
     ...
605 605
   </query>
606 606
 </iq>
607
-  ]]></example>
607
+]]></example>
608 608
   <p>If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.</p>
609 609
 </section1>
610 610
 <section1 topic='Security Considerations' anchor='security'>
@@ -733,7 +733,7 @@
733 733
   </xs:simpleType>
734 734
 
735 735
 </xs:schema>
736
-  ]]></code>
736
+]]></code>
737 737
 </section1>
738 738
 <section1 topic='Changes in Final State' anchor='final-changes'>
739 739
   <p>The following substantive protocol changes have been made while this specification has been in the Final state:</p>

+ 6
- 6
xep-0009.xml View File

@@ -89,7 +89,7 @@
89 89
     </methodCall>
90 90
   </query>
91 91
 </iq>
92
-  ]]></example>
92
+]]></example>
93 93
   <example caption='A typical response'><![CDATA[
94 94
 <iq type='result'
95 95
     from='responder@company-a.com/jrpc-server'
@@ -105,7 +105,7 @@
105 105
     </methodResponse>
106 106
   </query>
107 107
 </iq>
108
-  ]]></example>
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 111
 <iq type='error'
@@ -126,7 +126,7 @@
126 126
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
127 127
   </error>
128 128
 </iq>
129
-  ]]></example>
129
+]]></example>
130 130
 </section1>
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>
@@ -137,7 +137,7 @@
137 137
     id='disco1'>
138 138
   <query xmlns='http://jabber.org/protocol/disco#info'/>
139 139
 </iq>
140
-  ]]></example>
140
+]]></example>
141 141
   <example caption='A disco#info response'><![CDATA[
142 142
 <iq type='result'
143 143
     to='requester@company-b.com/jrpc-client'
@@ -148,7 +148,7 @@
148 148
     <feature var='jabber:iq:rpc'/>
149 149
   </query>
150 150
 </iq>
151
-  ]]></example>
151
+]]></example>
152 152
 </section1>
153 153
 <section1 topic='Security Considerations' anchor='security'>
154 154
   <p>An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
@@ -324,6 +324,6 @@
324 324
   </xs:simpleType>
325 325
 
326 326
 </xs:schema>
327
-  ]]></code>
327
+]]></code>
328 328
 </section1>
329 329
 </xep>

+ 1
- 1
xep-0011.xml View File

@@ -471,7 +471,7 @@
471 471
   <xs:element name='ns' type='xs:string'/>
472 472
 
473 473
 </xs:schema>
474
-    ]]></code>
474
+]]></code>
475 475
 </section1>
476 476
 <section1 topic='Future Considerations'>
477 477
   <p>The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this document will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.</p>

+ 14
- 14
xep-0012.xml View File

@@ -87,7 +87,7 @@
87 87
     type='get'>
88 88
   <query xmlns='jabber:iq:last'/>
89 89
 </iq>
90
-  ]]></example>
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 93
 <iq from='juliet@capulet.com'
@@ -96,7 +96,7 @@
96 96
     type='result'>
97 97
   <query xmlns='jabber:iq:last' seconds='903'/>
98 98
 </iq>
99
-  ]]></example>
99
+]]></example>
100 100
   <p>The requesting entity interprets the IQ-result based on the responding entity's JID type in order to determine the meaning of the information. Specifically, the information means something different depending on the identity of the responding entity:</p>
101 101
   <ol>
102 102
     <li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li>
@@ -114,7 +114,7 @@
114 114
     type='get'>
115 115
   <query xmlns='jabber:iq:last'/>
116 116
 </iq>
117
-  ]]></example>
117
+]]></example>
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[
@@ -126,7 +126,7 @@
126 126
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
127 127
   </error>
128 128
 </iq>
129
-  ]]></example>
129
+]]></example>
130 130
   <p>If the requesting entity is authorized to view the user's presence information, the server shall return information about the last presence activity recorded by the server for that user.</p>
131 131
   <example caption='Last Activity Response by Server'><![CDATA[
132 132
 <iq from='juliet@capulet.com'
@@ -135,7 +135,7 @@
135 135
     type='result'>
136 136
   <query xmlns='jabber:iq:last' seconds='903'>Heading Home</query>
137 137
 </iq>
138
-  ]]></example>
138
+]]></example>
139 139
   <p>In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence stanza of type='unavailable' whose &lt;status/&gt; element contained the text "Heading Home".</p>
140 140
   <p>If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty &lt;query/&gt; element whose 'seconds' attribute is set to a value of '0'.</p>
141 141
 </section1>
@@ -148,7 +148,7 @@
148 148
     type='get'>
149 149
   <query xmlns='jabber:iq:last'/>
150 150
 </iq>
151
-  ]]></example>
151
+]]></example>
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[
@@ -160,7 +160,7 @@
160 160
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
161 161
   </error>
162 162
 </iq>
163
-  ]]></example>
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 166
 <iq from='juliet@capulet.com/balcony'
@@ -169,7 +169,7 @@
169 169
     type='result'>
170 170
   <query xmlns='jabber:iq:last' seconds='123'/>
171 171
 </iq>
172
-  ]]></example>
172
+]]></example>
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[
@@ -181,7 +181,7 @@
181 181
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
182 182
   </error>
183 183
 </iq>
184
-  ]]></example>
184
+]]></example>
185 185
   <p>If there is no available resource matching the &LOCALBARE; in the 'to' attribute of the request, the server MUST follow the rules in <cite>XMPP IM</cite> in order to determine what error stanza to return.</p>
186 186
 </section1>
187 187
 <section1 topic='Server and Component Query' anchor='server'>
@@ -193,7 +193,7 @@
193 193
     type='get'>
194 194
   <query xmlns='jabber:iq:last'/>
195 195
 </iq>
196
-  ]]></example>
196
+]]></example>
197 197
   <example caption='Last Activity Response from Server or Service'><![CDATA[
198 198
 <iq from='capulet.com'
199 199
     id='last3'
@@ -201,7 +201,7 @@
201 201
     type='result'>
202 202
   <query xmlns='jabber:iq:last' seconds='123456'/>
203 203
 </iq>
204
-  ]]></example>
204
+]]></example>
205 205
   <p>In this example, the server has been running for a little more than 34 hours.</p>
206 206
 </section1>
207 207
 <section1 topic='Determining Support' anchor='support'>
@@ -213,7 +213,7 @@
213 213
     type='get'>
214 214
   <query xmlns='http://jabber.org/protocol/disco#info'/>
215 215
 </iq>
216
-  ]]></example>
216
+]]></example>
217 217
   <example caption='Responding entity communicates protocol support'><![CDATA[
218 218
 <iq from='jabber.org'
219 219
     id='disco1'
@@ -223,7 +223,7 @@
223 223
     <feature var='jabber:iq:last'/>
224 224
   </query>
225 225
 </iq>
226
-  ]]></example>
226
+]]></example>
227 227
   <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
228 228
 </section1>
229 229
 <section1 topic='Implementation Notes' anchor='impl'>
@@ -270,6 +270,6 @@
270 270
   </xs:element>
271 271
 
272 272
 </xs:schema>
273
-    ]]></code>
273
+]]></code>
274 274
 </section1>
275 275
 </xep>

+ 17
- 17
xep-0013.xml View File

@@ -124,7 +124,7 @@
124 124
 <iq type='get' to='montague.net'>
125 125
   <query xmlns='http://jabber.org/protocol/disco#info'/>
126 126
 </iq>
127
-    ]]></example>
127
+]]></example>
128 128
     <example caption='Server Reply to Discovery Request'><![CDATA[
129 129
 <iq type='result'
130 130
     from='montague.net'
@@ -133,7 +133,7 @@
133 133
     <feature var='http://jabber.org/protocol/offline'/>
134 134
   </query>
135 135
 </iq>
136
-    ]]></example>
136
+]]></example>
137 137
     <p>If the server supports this protocol, it MUST return a &lt;feature/&gt; element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
138 138
   </section2>
139 139
   <section2 topic='Requesting Number of Messages' anchor='request-number'>
@@ -144,7 +144,7 @@
144 144
   <query xmlns='http://jabber.org/protocol/disco#info'
145 145
          node='http://jabber.org/protocol/offline'/>
146 146
 </iq>
147
-    ]]></example>
147
+]]></example>
148 148
     <p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p>
149 149
     <example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
150 150
 <iq type='result' to='romeo@montague.net/orchard'>
@@ -164,7 +164,7 @@
164 164
     </x>
165 165
   </query>
166 166
 </iq>
167
-    ]]></example>
167
+]]></example>
168 168
     <p>Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.</p>
169 169
   </section2>
170 170
   <section2 topic='Requesting Message Headers' anchor='request-headers'>
@@ -174,7 +174,7 @@
174 174
   <query xmlns='http://jabber.org/protocol/disco#items'
175 175
          node='http://jabber.org/protocol/offline'/>
176 176
 </iq>
177
-    ]]></example>
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'>
@@ -202,7 +202,7 @@
202 202
         name='juliet@capulet.com/balcony'/>
203 203
   </query>
204 204
 </iq>
205
-    ]]></example>
205
+]]></example>
206 206
     <p>If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an &notfound; error. If there are no offline messages for this user, the server MUST return an empty query as defined in XEP-0030. (For information about the syntax of error conditions, refer to &xep0086;.)</p>
207 207
     <p>The syntax and semantics of the attributes are as follows:</p>
208 208
     <ul>
@@ -220,7 +220,7 @@
220 220
           node='2003-02-27T22:52:37.225Z'/>
221 221
   </offline>
222 222
 </iq>
223
-    ]]></example>
223
+]]></example>
224 224
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an &notfound; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p>
225 225
     <example caption='Server Provides Offline Messages'><![CDATA[
226 226
 <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@@ -231,7 +231,7 @@
231 231
 </message>
232 232
 
233 233
 <iq type='result' to='user@domain/resource' id='view1'/>
234
-    ]]></example>
234
+]]></example>
235 235
     <p>In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &xep0091; information in the message.</p>
236 236
   </section2>
237 237
   <section2 topic='Removing Specific Messages' anchor='remove-specific'>
@@ -246,11 +246,11 @@
246 246
           node='2003-02-27T22:52:37.225Z'/>
247 247
   </offline>
248 248
 </iq>
249
-    ]]></example>
249
+]]></example>
250 250
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove the messages and inform the user:</p>
251 251
     <example caption='Server Informs User of Removal'><![CDATA[
252 252
 <iq type='result' to='romeo@montague.net/orchard' id='remove1'/>
253
-    ]]></example>
253
+]]></example>
254 254
   </section2>
255 255
   <section2 topic='Retrieving All Messages' anchor='retrieve-all'>
256 256
     <p>The user retrieves all message by sending the "fetch" command:</p>
@@ -260,7 +260,7 @@
260 260
     <fetch/>
261 261
   </offline>
262 262
 </iq>
263
-    ]]></example>
263
+]]></example>
264 264
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST retrieve all messages and inform the user:</p>
265 265
     <example caption='Server Sends All Messages and Informs User of Successful Fetch'><![CDATA[
266 266
 <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@@ -271,7 +271,7 @@
271 271
 </message>
272 272
 
273 273
 <iq type='result' to='romeo@montague.net/orchard' id='fetch1'/>
274
-    ]]></example>
274
+]]></example>
275 275
     <p>A client MAY retrieve all messages without first requesting message headers. In this case, the server MUST return all of the user's offline messages and also MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. That is, the semantics here are the same as for requesting message headers.</p>
276 276
   </section2>
277 277
   <section2 topic='Removing All Messages' anchor='remove-all'>
@@ -282,11 +282,11 @@
282 282
     <purge/>
283 283
   </offline>
284 284
 </iq>
285
-    ]]></example>
285
+]]></example>
286 286
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove all messages and inform the user:</p>
287 287
     <example caption='Server Informs User of Successful Purge'><![CDATA[
288 288
 <iq type='result' to='romeo@montague.net/orchard' id='purge1'/>
289
-    ]]></example>
289
+]]></example>
290 290
   </section2>
291 291
 </section1>
292 292
 <section1 topic='Protocol Flow' anchor='flow'>
@@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc.
377 377
       <doc>XEP-0013</doc>
378 378
     </type>
379 379
   </category>
380
-    ]]></code>
380
+]]></code>
381 381
   </section2>
382 382
   <section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'>
383 383
     <p>The XMPP Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.</p>
@@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc.
397 397
       type='text-single'
398 398
       label='N/A'/>
399 399
 </form_type>
400
-    ]]></code>
400
+]]></code>
401 401
   </section2>
402 402
 </section1>
403 403
 <section1 topic='XML Schema' anchor='schema'>
@@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
441 441
   </xs:element>
442 442
 
443 443
 </xs:schema>
444
-  ]]></code>
444
+]]></code>
445 445
 </section1>
446 446
 </xep>

+ 56
- 56
xep-0016.xml View File

@@ -132,7 +132,7 @@
132 132
     </list>
133 133
   </query>
134 134
 </iq>
135
-    ]]></code>
135
+]]></code>
136 136
     <p>If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID.  JIDs SHOULD be matched in the following order:</p>
137 137
     <ol>
138 138
       <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
@@ -176,7 +176,7 @@
176 176
 <iq from='romeo@example.net/orchard' type='get' id='getlist1'>
177 177
 <query xmlns='jabber:iq:privacy'/>
178 178
 </iq>
179
-    ]]></example>
179
+]]></example>
180 180
     <example caption='Server sends names of privacy lists to client, preceded by active list and default list'><![CDATA[
181 181
 <iq type='result' id='getlist1' to='romeo@example.net/orchard'>
182 182
 <query xmlns='jabber:iq:privacy'>
@@ -187,14 +187,14 @@
187 187
   <list name='special'/>
188 188
 </query>
189 189
 </iq>
190
-    ]]></example>
190
+]]></example>
191 191
     <example caption='Client requests a privacy list from server'><![CDATA[
192 192
 <iq from='romeo@example.net/orchard' type='get' id='getlist2'>
193 193
 <query xmlns='jabber:iq:privacy'>
194 194
   <list name='public'/>
195 195
 </query>
196 196
 </iq>
197
-    ]]></example>
197
+]]></example>
198 198
     <example caption='Server sends a privacy list to client'><![CDATA[
199 199
 <iq type='result' id='getlist2' to='romeo@example.net/orchard'>
200 200
 <query xmlns='jabber:iq:privacy'>
@@ -207,14 +207,14 @@
207 207
   </list>
208 208
 </query>
209 209
 </iq>
210
-    ]]></example>
210
+]]></example>
211 211
     <example caption='Client requests another privacy list from server'><![CDATA[
212 212
 <iq from='romeo@example.net/orchard' type='get' id='getlist3'>
213 213
 <query xmlns='jabber:iq:privacy'>
214 214
   <list name='private'/>
215 215
 </query>
216 216
 </iq>
217
-    ]]></example>
217
+]]></example>
218 218
     <example caption='Server sends another privacy list to client'><![CDATA[
219 219
 <iq type='result' id='getlist3' to='romeo@example.net/orchard'>
220 220
 <query xmlns='jabber:iq:privacy'>
@@ -227,14 +227,14 @@
227 227
   </list>
228 228
 </query>
229 229
 </iq>
230
-    ]]></example>
230
+]]></example>
231 231
     <example caption='Client requests yet another privacy list from server'><![CDATA[
232 232
 <iq from='romeo@example.net/orchard' type='get' id='getlist4'>
233 233
 <query xmlns='jabber:iq:privacy'>
234 234
   <list name='special'/>
235 235
 </query>
236 236
 </iq>
237
-    ]]></example>
237
+]]></example>
238 238
     <example caption='Server sends yet another privacy list to client'><![CDATA[
239 239
 <iq type='result' id='getlist4' to='romeo@example.net/orchard'>
240 240
 <query xmlns='jabber:iq:privacy'>
@@ -255,7 +255,7 @@
255 255
   </list>
256 256
 </query>
257 257
 </iq>
258
-    ]]></example>
258
+]]></example>
259 259
     <p>In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.</p>
260 260
     <p>If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
261 261
     <example caption='Client attempts to retrieve non-existent list'><![CDATA[
@@ -268,7 +268,7 @@
268 268
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
269 269
 </error>
270 270
 </iq>
271
-    ]]></example>
271
+]]></example>
272 272
     <p>The user is allowed to retrieve only one list at a time.  If the user attempts to retrieve more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user:</p>
273 273
     <example caption='Client attempts to retrieve more than one list'><![CDATA[
274 274
 <iq to='romeo@example.net/orchard' type='error' id='getlist6'>
@@ -282,7 +282,7 @@
282 282
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
283 283
 </error>
284 284
 </iq>
285
-    ]]></example>
285
+]]></example>
286 286
   </section2>
287 287
   <section2 topic="Managing Active Lists" anchor="protocol-active">
288 288
     <p>In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;active/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@@ -292,11 +292,11 @@
292 292
   <active name='special'/>
293 293
 </query>
294 294
 </iq>
295
-    ]]></example>
295
+]]></example>
296 296
     <p>The server MUST activate and apply the requested list before sending the result back to the client.</p>
297 297
     <example caption='Server acknowledges success of active list change'><![CDATA[
298 298
 <iq type='result' id='active1' to='romeo@example.net/orchard'/>
299
-    ]]></example>
299
+]]></example>
300 300
     <p>If the user attempts to set an active list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
301 301
     <example caption='Client attempts to set a non-existent list as active'><![CDATA[
302 302
 <iq to='romeo@example.net/orchard' type='error' id='active2'>
@@ -308,7 +308,7 @@
308 308
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
309 309
 </error>
310 310
 </iq>
311
-    ]]></example>
311
+]]></example>
312 312
     <p>In order to decline the use of any active list, the connected resource MUST send an empty &lt;active/&gt; element with no 'name' attribute.</p>
313 313
     <example caption='Client declines the use of active lists'><![CDATA[
314 314
 <iq from='romeo@example.net/orchard' type='set' id='active3'>
@@ -316,10 +316,10 @@
316 316
   <active/>
317 317
 </query>
318 318
 </iq>
319
-    ]]></example>
319
+]]></example>
320 320
     <example caption='Server acknowledges success of declining any active list'><![CDATA[
321 321
 <iq type='result' id='active3' to='romeo@example.net/orchard'/>
322
-    ]]></example>
322
+]]></example>
323 323
   </section2>
324 324
   <section2 topic="Managing the Default List" anchor="protocol-default">
325 325
     <p>In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;default/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@@ -329,10 +329,10 @@
329 329
   <default name='special'/>
330 330
 </query>
331 331
 </iq>
332
-    ]]></example>
332
+]]></example>
333 333
     <example caption='Server acknowledges success of default list change'><![CDATA[
334 334
 <iq type='result' id='default1' to='romeo@example.net/orchard'/>
335
-    ]]></example>
335
+]]></example>
336 336
     <p>If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a &lt;conflict/&gt; stanza error to the sending resource:</p>
337 337
     <example caption='Client attempts to change the default list but that list is in use by another resource'><![CDATA[
338 338
 <iq to='romeo@example.net/orchard' type='error' id='default1'>
@@ -344,7 +344,7 @@
344 344
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
345 345
 </error>
346 346
 </iq>
347
-    ]]></example>
347
+]]></example>
348 348
     <p>If the user attempts to set a default list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
349 349
     <example caption='Client attempts to set a non-existent list as default'><![CDATA[
350 350
 <iq to='romeo@example.net/orchard' type='error' id='default1'>
@@ -356,7 +356,7 @@
356 356
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
357 357
 </error>
358 358
 </iq>
359
-    ]]></example>
359
+]]></example>
360 360
     <p>In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty &lt;default/&gt; element with no 'name' attribute.</p>
361 361
     <example caption='Client declines the use of the default list'><![CDATA[
362 362
 <iq from='romeo@example.net/orchard' type='set' id='default2'>
@@ -364,10 +364,10 @@
364 364
   <default/>
365 365
 </query>
366 366
 </iq>
367
-    ]]></example>
367
+]]></example>
368 368
     <example caption='Server acknowledges success of declining any default list'><![CDATA[
369 369
 <iq type='result' id='default2' to='romeo@example.net/orchard'/>
370
-    ]]></example>
370
+]]></example>
371 371
     <p>If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a &lt;conflict/&gt; error to the sending resource:</p>
372 372
     <example caption='Client attempts to decline a default list but that list is in use by another resource'><![CDATA[
373 373
 <iq to='romeo@example.net/orchard' type='error' id='default3'>
@@ -379,7 +379,7 @@
379 379
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
380 380
 </error>
381 381
 </iq>
382
-    ]]></example>
382
+]]></example>
383 383
   </section2>
384 384
   <section2 topic="Editing a Privacy List" anchor="protocol-edit">
385 385
     <p>In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains one &lt;list/&gt; child element possessing a 'name' attribute whose value is set to the list name the user would like to edit.  The &lt;list/&gt; element MUST contain one or more &lt;item/&gt; elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").</p>
@@ -399,10 +399,10 @@
399 399
   </list>
400 400
 </query>
401 401
 </iq>
402
-    ]]></example>
402
+]]></example>
403 403
     <example caption='Server acknowledges success of list edit'><![CDATA[
404 404
 <iq type='result' id='edit1' to='romeo@example.net/orchard'/>
405
-    ]]></example>
405
+]]></example>
406 406
     <p>Note: The value of the 'order' attribute for any given item is not fixed.  Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.</p>
407 407
     <p>The server MUST now send a "privacy list push" to all connected resources:</p>
408 408
     <example caption='Privacy list push on list edit'><![CDATA[
@@ -417,7 +417,7 @@
417 417
   <list name='public'/>
418 418
 </query>
419 419
 </iq>
420
-    ]]></example>
420
+]]></example>
421 421
     <p>In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:</p>
422 422
     <example caption='Acknowledging receipt of privacy list pushes'><![CDATA[
423 423
 <iq from='romeo@example.net/orchard'
@@ -427,7 +427,7 @@
427 427
 <iq from='romeo@example.net/home'
428 428
   type='result'
429 429
   id='push2'/>
430
-    ]]></example>
430
+]]></example>
431 431
   </section2>
432 432
   <section2 topic="Adding a New Privacy List" anchor="protocol-add">
433 433
     <p>The same protocol used to edit an existing list is used to create a new list.  If the list name matches that of an existing list, the request to add a new list will overwrite the old one.  As with list edits, the server MUST also send a "privacy list push" to all connected resources.</p>
@@ -440,10 +440,10 @@
440 440
   <list name='private'/>
441 441
 </query>
442 442
 </iq>
443
-    ]]></example>
443
+]]></example>
444 444
     <example caption='Server acknowledges success of list removal'><![CDATA[
445 445
 <iq type='result' id='remove1' to='romeo@example.net/orchard'/>
446
-    ]]></example>
446
+]]></example>
447 447
     <p>If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a &lt;conflict/&gt; stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it.  If the user attempts to remove a list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user.  If the user attempts to remove more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user.</p>
448 448
   </section2>
449 449
   <section2 topic="Blocking Messages" anchor="protocol-message">
@@ -461,7 +461,7 @@
461 461
   </list>
462 462
 </query>
463 463
 </iq>
464
-    ]]></example>
464
+]]></example>
465 465
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.</p>
466 466
     <example caption='User blocks based on roster group'><![CDATA[
467 467
 <iq from='romeo@example.net/orchard' type='set' id='msg2'>
@@ -476,7 +476,7 @@
476 476
   </list>
477 477
 </query>
478 478
 </iq>
479
-    ]]></example>
479
+]]></example>
480 480
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.</p>
481 481
     <example caption='User blocks based on subscription type'><![CDATA[
482 482
 <iq from='romeo@example.net/orchard' type='set' id='msg3'>
@@ -491,7 +491,7 @@
491 491
   </list>
492 492
 </query>
493 493
 </iq>
494
-    ]]></example>
494
+]]></example>
495 495
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.</p>
496 496
     <example caption='User blocks globally'><![CDATA[
497 497
 <iq from='romeo@example.net/orchard' type='set' id='msg4'>
@@ -503,7 +503,7 @@
503 503
   </list>
504 504
 </query>
505 505
 </iq>
506
-    ]]></example>
506
+]]></example>
507 507
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any other users.</p>
508 508
   </section2>
509 509
   <section2 topic="Blocking Inbound Presence Notifications" anchor="protocol-presencein">
@@ -522,7 +522,7 @@
522 522
   </list>
523 523
 </query>
524 524
 </iq>
525
-    ]]></example>
525
+]]></example>
526 526
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.</p>
527 527
     <example caption='User blocks based on roster group'><![CDATA[
528 528
 <iq from='romeo@example.net/orchard' type='set' id='presin2'>
@@ -537,7 +537,7 @@
537 537
   </list>
538 538
 </query>
539 539
 </iq>
540
-    ]]></example>
540
+]]></example>
541 541
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.</p>
542 542
     <example caption='User blocks based on subscription type'><![CDATA[
543 543
 <iq from='romeo@example.net/orchard' type='set' id='presin3'>
@@ -552,7 +552,7 @@
552 552
   </list>
553 553
 </query>
554 554
 </iq>
555
-    ]]></example>
555
+]]></example>
556 556
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.</p>
557 557
     <example caption='User blocks globally'><![CDATA[
558 558
 <iq from='romeo@example.net/orchard' type='set' id='presin4'>
@@ -564,7 +564,7 @@
564 564
   </list>
565 565
 </query>
566 566
 </iq>
567
-    ]]></example>
567
+]]></example>
568 568
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</p>
569 569
     <p>Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.</p>
570 570
   </section2>
@@ -584,7 +584,7 @@
584 584
   </list>
585 585
 </query>
586 586
 </iq>
587
-    ]]></example>
587
+]]></example>
588 588
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.</p>
589 589
     <example caption='User blocks based on roster group'><![CDATA[
590 590
 <iq from='romeo@example.net/orchard' type='set' id='presout2'>
@@ -599,7 +599,7 @@
599 599
   </list>
600 600
 </query>
601 601
 </iq>
602
-    ]]></example>
602
+]]></example>
603 603
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.</p>
604 604
     <example caption='User blocks based on subscription type'><![CDATA[
605 605
 <iq from='romeo@example.net/orchard' type='set' id='presout3'>
@@ -614,7 +614,7 @@
614 614
   </list>
615 615
 </query>
616 616
 </iq>
617
-    ]]></example>
617
+]]></example>
618 618
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.</p>
619 619
     <example caption='User blocks globally'><![CDATA[
620 620
 <iq from='romeo@example.net/orchard' type='set' id='presout4'>
@@ -626,7 +626,7 @@
626 626
   </list>
627 627
 </query>
628 628
 </iq>
629
-    ]]></example>
629
+]]></example>
630 630
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
631 631
     <p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
632 632
   </section2>
@@ -645,7 +645,7 @@
645 645
   </list>
646 646
 </query>
647 647
 </iq>
648
-    ]]></example>
648
+]]></example>
649 649
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.</p>
650 650
     <example caption='User blocks based on roster group'><![CDATA[
651 651
 <iq from='romeo@example.net/orchard' type='set' id='iq2'>
@@ -660,7 +660,7 @@
660 660
   </list>
661 661
 </query>
662 662
 </iq>
663
-    ]]></example>
663
+]]></example>
664 664
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.</p>
665 665
     <example caption='User blocks based on subscription type'><![CDATA[
666 666
 <iq from='romeo@example.net/orchard' type='set' id='iq3'>
@@ -675,7 +675,7 @@
675 675
   </list>
676 676
 </query>
677 677
 </iq>
678
-    ]]></example>
678
+]]></example>
679 679
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.</p>
680 680
     <example caption='User blocks globally'><![CDATA[
681 681
 <iq from='romeo@example.net/orchard' type='set' id='iq4'>
@@ -687,7 +687,7 @@
687 687
   </list>
688 688
 </query>
689 689
 </iq>
690
-    ]]></example>
690
+]]></example>
691 691
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.</p>
692 692
   </section2>
693 693
   <section2 topic="Blocking All Communication" anchor="protocol-all">
@@ -703,7 +703,7 @@
703 703
   </list>
704 704
 </query>
705 705
 </iq>
706
-    ]]></example>
706
+]]></example>
707 707
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.</p>
708 708
     <example caption='User blocks based on roster group'><![CDATA[
709 709
 <iq from='romeo@example.net/orchard' type='set' id='all2'>
@@ -716,7 +716,7 @@
716 716
   </list>
717 717
 </query>
718 718
 </iq>
719
-    ]]></example>
719
+]]></example>
720 720
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.</p>
721 721
     <example caption='User blocks based on subscription type'><![CDATA[
722 722
 <iq from='romeo@example.net/orchard' type='set' id='all3'>
@@ -729,7 +729,7 @@
729 729
   </list>
730 730
 </query>
731 731
 </iq>
732
-    ]]></example>
732
+]]></example>
733 733
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.</p>
734 734
     <example caption='User blocks globally'><![CDATA[
735 735
 <iq from='romeo@example.net/orchard' type='set' id='all4'>
@@ -739,7 +739,7 @@
739 739
   </list>
740 740
 </query>
741 741
 </iq>
742
-    ]]></example>
742
+]]></example>
743 743
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.</p>
744 744
   </section2>
745 745
   <section2 topic="Blocked Entity Attempts to Communicate with User" anchor="protocol-error">
@@ -757,7 +757,7 @@
757 757
   id='probing1'>
758 758
 <query xmlns='jabber:iq:version'/>
759 759
 </iq>
760
-    ]]></example>
760
+]]></example>
761 761
     <example caption='Server returns error to blocked entity'><![CDATA[
762 762
 <iq type='error'
763 763
   from='romeo@example.net'
@@ -769,7 +769,7 @@
769 769
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
770 770
 </error>
771 771
 </iq>
772
-    ]]></example>
772
+]]></example>
773 773
     <p>If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a &notacceptable; error:</p>
774 774
     <example caption='Error: contact is blocked'><![CDATA[
775 775
 <message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
@@ -778,7 +778,7 @@
778 778
     <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
779 779
   </error>
780 780
 </message>
781
-    ]]></example>
781
+]]></example>
782 782
   </section2>
783 783
   <section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics">
784 784
     <p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p>
@@ -801,7 +801,7 @@
801 801
   </list>
802 802
 </query>
803 803
 </iq>
804
-    ]]></code>
804
+]]></code>
805 805
   </section2>
806 806
 </section1>
807 807
 
@@ -814,7 +814,7 @@
814 814
     type='get'>
815 815
   <query xmlns='http://jabber.org/protocol/disco#info'/>
816 816
 </iq>
817
-  ]]></example>
817
+]]></example>
818 818
   <example caption="Service Discovery information response"><![CDATA[
819 819
 <iq from='example.com'
820 820
     id='disco1'
@@ -826,7 +826,7 @@
826 826
     ...
827 827
   </query>
828 828
 </iq>
829
-  ]]></example>
829
+]]></example>
830 830
 </section1>
831 831
 
832 832
 <section1 topic='Implementation Notes' anchor='impl'>
@@ -962,7 +962,7 @@
962 962
 </xs:simpleType>
963 963
 
964 964
 </xs:schema>
965
-  ]]></code>
965
+]]></code>
966 966
 </section1>
967 967
 
968 968
 <section1 topic='Author Note' anchor='authornote'>

+ 6
- 6
xep-0020.xml View File

@@ -120,7 +120,7 @@
120 120
     </x>
121 121
   </feature>
122 122
 </iq>
123
-    ]]></example>
123
+]]></example>
124 124
     <example caption="Responding entity sends preferred option values"><![CDATA[
125 125
 <iq type='result'
126 126
     id='neg1'
@@ -140,7 +140,7 @@
140 140
     </x>
141 141
   </feature>
142 142
 </iq>
143
-    ]]></example>
143
+]]></example>
144 144
     <p>Note: If the responding entity does not want to reveal presence to the initiating entity for whatever reason then the responding entity's client SHOULD return a &unavailable; error (or return no response or error whatsoever if the offer was wrapped in a &MESSAGE; stanza) - see <link url='#security'>Security Considerations</link>.</p>
145 145
     <p>If the responding entity does not support <strong>Feature Negotiation</strong> or does not support the specified FORM_TYPE, it SHOULD also return a &unavailable; error:</p>
146 146
     <example caption="Responding entity does not support feature negotiation"><![CDATA[
@@ -160,7 +160,7 @@
160 160
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
161 161
   </error>
162 162
 </iq>
163
-    ]]></example>
163
+]]></example>
164 164
     <p>If the responding entity does not support one or more of the features, it SHOULD return a &feature; error, and SHOULD specify the feature(s) not implemented in the XMPP &lt;text/&gt; element.</p>
165 165
     <example caption="Responding entity does not support a feature"><![CDATA[
166 166
 <iq type='error'
@@ -180,7 +180,7 @@
180 180
     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>times-to-meet</text>
181 181
   </error>
182 182
 </iq>
183
-    ]]></example>
183
+]]></example>
184 184
     <p>If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a &notacceptable; error, and SHOULD specify the relevant feature(s) in the XMPP &lt;text/&gt; element.</p>
185 185
     <example caption="Responding entity supports no options"><![CDATA[
186 186
 <iq type='error'
@@ -200,7 +200,7 @@
200 200
     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>places-to-meet</text>
201 201
   </error>
202 202
 </iq>
203
-    ]]></example>
203
+]]></example>
204 204
   </section2>
205 205
   <section2 topic="Querying for Negotiable Features" anchor='protocol-query'>
206 206
     <p>If at least one feature offered by an entity is subject to <strong>Feature Negotiation</strong>, the entity's response to a service discovery information request MUST include &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p>
@@ -314,7 +314,7 @@
314 314
   </xs:element>
315 315
 
316 316
 </xs:schema>
317
-  ]]></code>
317
+]]></code>
318 318
 </section1>
319 319
 <section1 topic='Author Note' anchor='authornote'>
320 320
   <p>Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining authors are thankful for Peter's work on this specification.</p>

+ 13
- 13
xep-0022.xml View File

@@ -121,7 +121,7 @@
121 121
     <composing/>
122 122
   </x>
123 123
 </message>
124
-  ]]></example>
124
+]]></example>
125 125
   <p>Here we see the sender wants to be notified if the message is stored offline (by the server), notified when the message is delivered (to the client), and notified if the recipient begins replying to the message. In this case, the sender will potentially receive three events based on this request.  The first if the recipient is offline and the message is stored on the server, the second when the recipient becomes available and the message is delivered, and the third if the recipient begins composing a reply to the message.</p>
126 126
   <p>Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.</p>
127 127
   </section2>
@@ -137,7 +137,7 @@
137 137
     <id>message22</id>
138 138
   </x>
139 139
 </message>
140
-  ]]></example>
140
+]]></example>
141 141
   <p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p>
142 142
     <ul>
143 143
       <li>The element must contain only a jabber:x:event extension. Standard message elements such as &lt;subject/&gt;, &lt;body/&gt;, MUST NOT be included.</li>
@@ -160,7 +160,7 @@
160 160
     <id>message22</id>
161 161
   </x>
162 162
 </message>
163
-  ]]></example>
163
+]]></example>
164 164
   <example caption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[
165 165
 <message
166 166
     from='romeo@montague.net'
@@ -169,7 +169,7 @@
169 169
     <id>message22</id>
170 170
   </x>
171 171
 </message>
172
-  ]]></example>
172
+]]></example>
173 173
   <p>The lack of an &lt;composing/&gt; tag (and any other event tag) signifies that the composing event, indicated previously by the id value, has been cancelled. In this example, the composing event being cancelled is that event that was previously raised with the id of message22.  After cancelling a composing event, a new one may be raised, following the same rules as before, when the typing of the reply is resumed.</p>
174 174
   </section2>
175 175
 </section1>
@@ -186,7 +186,7 @@ SEND: <message to='romeo@montague.net' id='message22'>
186 186
         <composing/>
187 187
       </x>
188 188
     </message>
189
-  ]]></example>
189
+]]></example>
190 190
   <p>Romeo temporarily loses his wireless connection in the Capulet's orchard and therefore his message is stored offline by the montague.net server, which generates the offline event and sends that notification to Juliet.</p>
191 191
   <example caption='Receiving the offline event'><![CDATA[
192 192
 RECV: <message
@@ -197,7 +197,7 @@ RECV: <message
197 197
         <id>message22</id>
198 198
       </x>
199 199
     </message>
200
-  ]]></example>
200
+]]></example>
201 201
   <p>Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.</p>
202 202
   <example caption='Juliet receives notification of message delivery'><![CDATA[
203 203
 RECV: <message
@@ -208,7 +208,7 @@ RECV: <message
208 208
         <id>message22</id>
209 209
       </x>
210 210
     </message>
211
-  ]]></example>
211
+]]></example>
212 212
   <p>Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.</p>
213 213
   <example caption='Juliet receives notification of message display'><![CDATA[
214 214
 RECV: <message
@@ -219,7 +219,7 @@ RECV: <message
219 219
         <id>message22</id>
220 220
       </x>
221 221
     </message>
222
-  ]]></example>
222
+]]></example>
223 223
   <p>Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.</p>
224 224
   <example caption='Juliet receives notification of message composing'><![CDATA[
225 225
 RECV: <message
@@ -230,7 +230,7 @@ RECV: <message
230 230
         <id>message22</id>
231 231
       </x>
232 232
     </message>
233
-  ]]></example>
233
+]]></example>
234 234
   <p>Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.</p>
235 235
   <example caption='Juliet receives cancellation of message composing'><![CDATA[
236 236
 RECV: <message
@@ -240,7 +240,7 @@ RECV: <message
240 240
         <id>message22</id>
241 241
       </x>
242 242
     </message>
243
-  ]]></example>
243
+]]></example>
244 244
   <p>Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.</p>
245 245
   <example caption='Juliet receives a second notification of message composing'><![CDATA[
246 246
 RECV: <message
@@ -251,7 +251,7 @@ RECV: <message
251 251
         <id>message22</id>
252 252
       </x>
253 253
     </message>
254
-  ]]></example>
254
+]]></example>
255 255
   <p>Romeo finally sends his reply, and requests composing events related to it.</p>
256 256
   <example caption='Romeo replies'><![CDATA[
257 257
 SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
@@ -260,7 +260,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
260 260
         <composing/>
261 261
       </x>
262 262
     </message>
263
-  ]]></example>
263
+]]></example>
264 264
 </section1>
265 265
 
266 266
 <section1 topic='Implementation Notes'>
@@ -319,7 +319,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
319 319
   </xs:simpleType>
320 320
 
321 321
 </xs:schema>
322
-    ]]></code>
322
+]]></code>
323 323
 </section1>
324 324
 
325 325
 <section1 topic='Open Issues'>

+ 1
- 1
xep-0023.xml View File

@@ -168,7 +168,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
168 168
   </xs:simpleType>
169 169
 
170 170
 </xs:schema>
171
-    ]]></code>
171
+]]></code>
172 172
 </section1>
173 173
 
174 174
 <section1 topic='Open Issues'>

+ 2
- 2
xep-0027.xml View File

@@ -163,7 +163,7 @@
163 163
   <xs:element name='x' type='xs:string'/>
164 164
 
165 165
 </xs:schema>
166
-    ]]></code>
166
+]]></code>
167 167
   </section2>
168 168
   <section2 topic='jabber:x:signed' anchor='schemas-signed'>
169 169
     <code><![CDATA[
@@ -185,7 +185,7 @@
185 185
   <xs:element name='x' type='xs:string'/>
186 186
 
187 187
 </xs:schema>
188
-    ]]></code>
188
+]]></code>
189 189
   </section2>
190 190
 </section1>
191 191
 </xep>

+ 34
- 34
xep-0030.xml View File

@@ -276,7 +276,7 @@
276 276
     id='info1'>
277 277
   <query xmlns='http://jabber.org/protocol/disco#info'/>
278 278
 </iq>
279
-      ]]></example>
279
+]]></example>
280 280
       <p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.)</p>
281 281
       <p>Each &lt;identity/&gt; element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the &lt;identity/&gt; element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the &lt;query/&gt; element MAY include multiple &lt;identity/&gt; elements with the same category+type but with different 'xml:lang' values, however the &lt;query/&gt; element MUST NOT include multiple &lt;identity/&gt; elements with the same category+type+xml:lang but with different 'name' values).</p>
282 282
       <p>Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity, and MUST NOT have any children.</p>
@@ -304,7 +304,7 @@
304 304
     <feature var='jabber:iq:version'/>
305 305
   </query>
306 306
 </iq>
307
-    ]]></example>
307
+]]></example>
308 308
       <p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <cite>XMPP Core</cite> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p>
309 309
       <example caption='Target entity does not exist'><![CDATA[
310 310
 <iq type='error'
@@ -316,7 +316,7 @@
316 316
     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
317 317
   </error>
318 318
 </iq>
319
-      ]]></example>
319
+]]></example>
320 320
       <p>If privacy and security considerations or policies prevent the server or other authoritative entity from returning an &notfound; error, it SHOULD return a &unavailable; error instead:</p>
321 321
       <example caption='Service unavailable'><![CDATA[
322 322
 <iq type='error'
@@ -328,7 +328,7 @@
328 328
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
329 329
   </error>
330 330
 </iq>
331
-      ]]></example>
331
+]]></example>
332 332
       <p>When an entity sends a disco#info request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).</p>
333 333
       <example caption='Requesting info from a bare JID'><![CDATA[
334 334
 <iq type='get'
@@ -337,7 +337,7 @@
337 337
     id='info2'>
338 338
   <query xmlns='http://jabber.org/protocol/disco#info'/>
339 339
 </iq>
340
-      ]]></example>
340
+]]></example>
341 341
       <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; is a registered account:</p>
342 342
       <example caption='Server replies on behalf of bare JID'><![CDATA[
343 343
 <iq type='result'
@@ -349,7 +349,7 @@
349 349
     <feature var='http://jabber.org/protocol/disco#info'/>
350 350
   </query>
351 351
 </iq>
352
-      ]]></example>
352
+]]></example>
353 353
       <p>A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:</p>
354 354
       <example caption='Querying a specific conference room'><![CDATA[
355 355
 <iq type='get'
@@ -401,7 +401,7 @@
401 401
     <feature var='jabber:iq:version'/>
402 402
   </query>
403 403
 </iq>
404
-      ]]></example>
404
+]]></example>
405 405
     </section2>
406 406
     <section2 topic='Info Nodes' anchor='info-nodes'>
407 407
       <p>A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as <link url='#items-nodes'>Items Nodes</link> rather than as info nodes:</p>
@@ -413,7 +413,7 @@
413 413
   <query xmlns='http://jabber.org/protocol/disco#info'
414 414
          node='http://jabber.org/protocol/commands'/>
415 415
 </iq>
416
-      ]]></example>
416
+]]></example>
417 417
       <p>If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.</p>
418 418
       <example caption='JID+node result'><![CDATA[
419 419
 <iq type='result'
@@ -428,7 +428,7 @@
428 428
     <feature var='http://jabber.org/protocol/disco#info'/>
429 429
   </query>
430 430
 </iq>
431
-      ]]></example>
431
+]]></example>
432 432
     </section2>
433 433
   </section1>
434 434
 
@@ -442,7 +442,7 @@
442 442
     id='items1'>
443 443
   <query xmlns='http://jabber.org/protocol/disco#items'/>
444 444
 </iq>
445
-      ]]></example>
445
+]]></example>
446 446
       <p>The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an &lt;item/&gt; child of a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the &lt;item/&gt; child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):</p>
447 447
       <example caption='Result-set for all items'><![CDATA[
448 448
 <iq type='result'
@@ -468,7 +468,7 @@
468 468
           name='French Translation Service'/>
469 469
   </query>
470 470
 </iq>
471
-      ]]></example>
471
+]]></example>
472 472
       <p>The &lt;item/&gt; element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.</p>
473 473
       <p>If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:</p>
474 474
       <example caption='Empty result set'><![CDATA[
@@ -478,7 +478,7 @@
478 478
     id='items1'>
479 479
   <query xmlns='http://jabber.org/protocol/disco#items'/>
480 480
 </iq>
481
-      ]]></example>
481
+]]></example>
482 482
       <p>As with disco#info requests, when an entity sends a disco#items request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:</p>
483 483
       <example caption='Requesting items from a bare JID'><![CDATA[
484 484
 <iq type='get'
@@ -487,7 +487,7 @@
487 487
     id='items2'>
488 488
   <query xmlns='http://jabber.org/protocol/disco#items'/>
489 489
 </iq>
490
-      ]]></example>
490
+]]></example>
491 491
       <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; has two available resources:</p>
492 492
       <example caption='Server replies on behalf of bare JID'><![CDATA[
493 493
 <iq type='result'
@@ -499,7 +499,7 @@
499 499
     <item jid='juliet@capulet.com/chamber'/>
500 500
   </query>
501 501
 </iq>
502
-      ]]></example>
502
+]]></example>
503 503
     </section2>
504 504
     <section2 topic='Items Nodes' anchor='items-nodes'>
505 505
       <p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p>
@@ -512,7 +512,7 @@
512 512
     id='items2'>
513 513
   <query xmlns='http://jabber.org/protocol/disco#items'/>
514 514
 </iq>
515
-        ]]></example>
515
+]]></example>
516 516
         <p>If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each &lt;item/&gt; element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):</p>
517 517
         <example caption='Service returns nodes'><![CDATA[
518 518
 <iq type='result'
@@ -531,7 +531,7 @@
531 531
           name='Music from the time of Shakespeare'/>
532 532
   </query>
533 533
 </iq>
534
-      ]]></example>
534
+]]></example>
535 535
       <p>There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.</p>
536 536
       <example caption='Requesting further nodes'><![CDATA[
537 537
 <iq type='get'
@@ -541,7 +541,7 @@
541 541
   <query xmlns='http://jabber.org/protocol/disco#items'
542 542
          node='music'/>
543 543
 </iq>
544
-      ]]></example>
544
+]]></example>
545 545
       <p>The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.</p>
546 546
       <example caption='Service returns further nodes'><![CDATA[
547 547
 <iq type='result'
@@ -563,7 +563,7 @@
563 563
     .
564 564
   </query>
565 565
 </iq>
566
-      ]]></example>
566
+]]></example>
567 567
       <p>The requesting entity can then query further if desired:</p>
568 568
       <example caption='Requesting even more nodes'><![CDATA[
569 569
 <iq type='get'
@@ -573,7 +573,7 @@
573 573
   <query xmlns='http://jabber.org/protocol/disco#items'
574 574
          node='music/D'/>
575 575
 </iq>
576
-      ]]></example>
576
+]]></example>
577 577
       <example caption='Service returns even more nodes'><![CDATA[
578 578
 <iq type='result'
579 579
     from='catalog.shakespeare.lit'
@@ -589,7 +589,7 @@
589 589
           name='John Dowland - A Pilgrimes Solace'/>
590 590
   </query>
591 591
 </iq>
592
-      ]]></example>
592
+]]></example>
593 593
     </section2>
594 594
     <section2 topic='Node Hierarchies' anchor='items-hierarchy'>
595 595
       <p>The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.</p>
@@ -616,7 +616,7 @@
616 616
   <query xmlns='http://jabber.org/protocol/disco#items'
617 617
          node='http://jabber.org/protocol/tune'/>
618 618
 </iq>
619
-      ]]></example>
619
+]]></example>
620 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'
@@ -634,7 +634,7 @@
634 634
           node='g8k4kds9sd89djf3'/>
635 635
   </query>
636 636
 </iq>
637
-      ]]></example>
637
+]]></example>
638 638
     </section2>
639 639
   </section1>
640 640
 
@@ -667,7 +667,7 @@
667 667
     <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
668 668
   </error>
669 669
 </iq>
670
-    ]]></example>
670
+]]></example>
671 671
     <p>Other error conditions may be appropriate depending on the application.</p>
672 672
     <p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).</p>
673 673
     <table caption='Error Conditions'>
@@ -731,7 +731,7 @@
731 731
     <doc>the document (e.g., XEP) in which this type is specified</doc>
732 732
   </type>
733 733
 </category>
734
-          ]]></code>
734
+]]></code>
735 735
           <p>The registrant may register more than one category at a time, each contained in a separate &lt;category/&gt; element. The registrant may also register more than one type at a time, each contained in a separate &lt;type/&gt; child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).</p>
736 736
         </section4>
737 737
         <section4 topic='Initial Submission' anchor='registrar-reg-identity-init'>
@@ -760,7 +760,7 @@
760 760
     <doc>XEP-0030</doc>
761 761
   </type>
762 762
 </category>
763
-          ]]></code>
763
+]]></code>
764 764
         </section4>
765 765
       </section3>
766 766
       <section3 topic='Features Registry' anchor='registrar-reg-features'>
@@ -773,7 +773,7 @@
773 773
   <desc>a natural-language description of the feature</desc>
774 774
   <doc>the document (e.g., XEP) in which this feature is specified</doc>
775 775
 </var>
776
-          ]]></code>
776
+]]></code>
777 777
           <p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p>
778 778
         </section4>
779 779
       </section3>
@@ -787,7 +787,7 @@
787 787
   <desc>a natural-language description of the node</desc>
788 788
   <doc>the document (e.g., XEP) in which this node is specified</doc>
789 789
 </node>
790
-          ]]></code>
790
+]]></code>
791 791
           <p>The registrant may register more than one node at a time, each contained in a separate &lt;node/&gt; element.</p>
792 792
         </section4>
793 793
       </section3>
@@ -797,20 +797,20 @@
797 797
       <p>The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).</p>
798 798
       <example caption='Service Discovery Information Request: IRI/URI'><![CDATA[
799 799
 xmpp:romeo@montague.net?disco;type=get;request=info
800
-      ]]></example>
800
+]]></example>
801 801
       <example caption='Service Discovery Information Request: Resulting Stanza'><![CDATA[
802 802
 <iq to='romeo@montague.net' type='get'>
803 803
   <query xmlns='http://jabber.org/protocol/disco#info'/>
804 804
 </iq>
805
-      ]]></example>
805
+]]></example>
806 806
       <example caption='Service Discovery Items Request: IRI/URI'><![CDATA[
807 807
 xmpp:romeo@montague.net?disco;type=get;request=items
808
-      ]]></example>
808
+]]></example>
809 809
       <example caption='Service Discovery Items Request: Resulting Stanza'><![CDATA[
810 810
 <iq to='romeo@montague.net' type='get'>
811 811
   <query xmlns='http://jabber.org/protocol/disco#items'/>
812 812
 </iq>
813
-      ]]></example>
813
+]]></example>
814 814
       <p>The following submission registers the "disco" querytype.</p>
815 815
       <code><![CDATA[
816 816
 <querytype>
@@ -850,7 +850,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
850 850
   </keys>
851 851
 </querytype>
852 852
 
853
-      ]]></code>
853
+]]></code>
854 854
     </section2>
855 855
   </section1>
856 856
   <section1 topic='XML Schemas' anchor='schemas'>
@@ -916,7 +916,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
916 916
   </xs:simpleType>
917 917
 
918 918
 </xs:schema>
919
-      ]]></code>
919
+]]></code>
920 920
     </section2>
921 921
     <section2 topic='disco#items' anchor='schemas-items'>
922 922
       <code><![CDATA[
@@ -970,7 +970,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
970 970
   </xs:simpleType>
971 971
 
972 972
 </xs:schema>
973
-      ]]></code>
973
+]]></code>
974 974
     </section2>
975 975
   </section1>
976 976
 <section1 topic='Author Note' anchor='authornote'>

+ 1
- 1
xep-0033.xml View File

@@ -703,7 +703,7 @@
703 703
   </xs:simpleType>
704 704
 
705 705
 </xs:schema>
706
-        ]]></code>
706
+]]></code>
707 707
     </section1>
708 708
 
709 709
     <section1 topic='Acknowledgements' anchor='ack'>

+ 2
- 2
xep-0038.xml View File

@@ -288,7 +288,7 @@
288 288
     </xs:complexType>
289 289
   </xs:element>
290 290
 </xs:schema>
291
-    ]]></code>
291
+]]></code>
292 292
   </section2>
293 293
 
294 294
   <section2 topic="icondef.xml file example">
@@ -342,7 +342,7 @@
342 342
     <object mime="audio/x-wav">alert.wav</object>
343 343
   </icon>
344 344
 </icondef>
345
-    ]]></code>
345
+]]></code>
346 346
   </section2>
347 347
 </section1>
348 348
 

+ 1
- 1
xep-0041.xml View File

@@ -264,7 +264,7 @@
264 264
    </xs:element>
265 265
 
266 266
 </xs:schema>
267
-  ]]></code>
267
+]]></code>
268 268
 </section1>
269 269
 
270 270
 </xep>

+ 39
- 39
xep-0042.xml View File

@@ -118,7 +118,7 @@
118 118
 <iq type='get' to='domain'>
119 119
   <query xmlns='jabber:iq:browse'/>
120 120
 </iq>
121
-      ]]></example>
121
+]]></example>
122 122
       <example caption='Browse result'><![CDATA[
123 123
 <iq type='get' to='sender@domain/res' from='domain'>
124 124
   ...
@@ -131,7 +131,7 @@
131 131
   </item>
132 132
   ...
133 133
 </iq>
134
-      ]]></example>
134
+]]></example>
135 135
     </section3>
136 136
   </section2>
137 137
   <section2 topic='Creating a Session'>
@@ -147,7 +147,7 @@
147 147
   <session xmlns='http://jabber.org/protocol/jobs'
148 148
       action='create'/>
149 149
 </iq>
150
-      ]]></example>
150
+]]></example>
151 151
       <example caption='Creation result'><![CDATA[
152 152
 <iq
153 153
     type='result' to='sender@domain/res' from='jobs.domain'>
@@ -161,7 +161,7 @@
161 161
       expires='30'
162 162
       receivers='1'/>
163 163
 </iq>
164
-      ]]></example>
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>
@@ -174,7 +174,7 @@
174 174
 <iq id='JOBS0' type='get' to='jobs.domain'>
175 175
   <session xmlns='http://jabber.org/protocol/jobs' action='create'/>
176 176
 </iq>
177
-      ]]></example>
177
+]]></example>
178 178
       <example caption='Parameter statistics result'><![CDATA[
179 179
 <iq id='JOBS0' type='result' to='sender@domain/res' from='jobs.domain'>
180 180
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -199,7 +199,7 @@
199 199
         min='1'/>
200 200
   </session>
201 201
 </iq>
202
-      ]]></example>
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
 
@@ -209,7 +209,7 @@
209 209
   <session xmlns='http://jabber.org/protocol/jobs' action='create'
210 210
       expires='-1'/>
211 211
 </iq>
212
-      ]]></example>
212
+]]></example>
213 213
       <example caption='Creation result, with parameters'><![CDATA[
214 214
 <iq type='result' to='sender@domain/res' from='jobs.domain'>
215 215
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -222,7 +222,7 @@
222 222
       expires='-1'
223 223
       receivers='1'/>
224 224
 </iq>
225
-      ]]></example>
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
 
@@ -239,7 +239,7 @@
239 239
     <x xmlns='jabber:x:data'/>
240 240
   </session>
241 241
 </iq>
242
-      ]]></example>
242
+]]></example>
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'
@@ -259,7 +259,7 @@
259 259
     </x>
260 260
   </session>
261 261
 </iq>
262
-      ]]></example>
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>
@@ -275,7 +275,7 @@
275 275
     </x>
276 276
   </session>
277 277
 </iq>
278
-      ]]></example>
278
+]]></example>
279 279
       <example caption='Creation result (form-based)'><![CDATA[
280 280
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
281 281
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -288,7 +288,7 @@
288 288
       expires='300'
289 289
       receivers='1'/>
290 290
 </iq>
291
-      ]]></example>
291
+]]></example>
292 292
     </section3>
293 293
   </section2>
294 294
   <section2 topic='Inviting Receivers'>
@@ -308,7 +308,7 @@
308 308
       expires='30'
309 309
       receivers='1'/>
310 310
 </message>
311
-      ]]></example>
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>
@@ -327,7 +327,7 @@
327 327
       id='01234567'>
328 328
     <item type='connection' action='invite'>receiver@domain</item>
329 329
 </message>
330
-      ]]></example>
330
+]]></example>
331 331
       <p>This results in the JOBS service sending the &lt;message/&gt; to each &lt;item/&gt;. Any additional elements (such as a &lt;body/&gt;) are passed onto those invited:</p>
332 332
       <example caption='Invitation message (from JOBS service)'><![CDATA[
333 333
 <message from='jobs.domain' to='receiver@domain'>
@@ -344,7 +344,7 @@
344 344
       receivers='1'>
345 345
     <item type='connection' action='invite'/>
346 346
 </message>
347
-      ]]></example>
347
+]]></example>
348 348
     </section3>
349 349
   </section2>
350 350
   <section2 topic='Retrieving Session Information'>
@@ -357,7 +357,7 @@
357 357
   <session xmlns='http://jabber.org/protocol/jobs'
358 358
       action='info'/>
359 359
 </iq>
360
-      ]]></example>
360
+]]></example>
361 361
       <p>The JOBS service responds with all the sessions within the "iq-result". This is the only case where a result can have more than one &lt;session/&gt;.</p>
362 362
       <example caption='Information result (all sessions)'><![CDATA[
363 363
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
@@ -382,7 +382,7 @@
382 382
       expires='30'
383 383
       receivers='1'/>
384 384
 </iq>
385
-      ]]></example>
385
+]]></example>
386 386
     </section3>
387 387
     <section3 topic='Session-specific'>
388 388
       <p>Alternatively, a client can request the information for a specific session by sending an "iq-get" containing a &lt;session action="info"/&gt; with the ID:</p>
@@ -392,7 +392,7 @@
392 392
       action='info'
393 393
       id='01234567'/>
394 394
 </iq>
395
-      ]]></example>
395
+]]></example>
396 396
       <p>The service responds with an "iq-result" of just the requested session.</p>
397 397
       <example caption='Information result (session-specific)'><![CDATA[
398 398
 <iq type='result' from='jobs.domain' sender='sender@domain/res'>
@@ -408,7 +408,7 @@
408 408
     <item type='connection' action='accept'>sender@domain/res</item>
409 409
   </session>
410 410
 </iq>
411
-      ]]></example>
411
+]]></example>
412 412
     </section3>
413 413
   </section2>
414 414
   <section2 topic='Connecting OOB'>
@@ -422,7 +422,7 @@ jobs/0.4 init
422 422
 session-id: 01234567
423 423
 client-jid: sender@domain/res
424 424
 
425
-      ]]></example>
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
 
@@ -430,7 +430,7 @@ client-jid: sender@domain/res
430 430
 jobs/0.4 auth-challenge
431 431
 confirm: SID00001234
432 432
 
433
-      ]]></example>
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
 
@@ -442,7 +442,7 @@ confirm: SID00001234
442 442
       <item type='auth' action='confirm'>SID00001234</item>
443 443
     </session>
444 444
   </iq>hehe
445
-      ]]></example>
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
 
@@ -455,7 +455,7 @@ confirm: SID00001234
455 455
       <item type='auth' action='accept'>SID88884321</accept>
456 456
     </session>
457 457
   </iq>
458
-    ]]></example>
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
 
@@ -463,14 +463,14 @@ confirm: SID00001234
463 463
   jobs/0.4 auth-response
464 464
   accept: SID88884321
465 465
 
466
-    ]]></example>
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
 
473
-      ]]></example>
473
+]]></example>
474 474
       <p>and after this, the data transfer occurs. If this connection is the sender, they may start sending data now (regardless if receivers are connected). If this connection is a receiver, the sender's data immediately follows the terminating "newline".</p>
475 475
     </section3>
476 476
     <section3 topic='Authorizing'>
@@ -487,7 +487,7 @@ confirm: SID00001234
487 487
     <item type='connection' action='confirm'>receiver@domain/res</item>
488 488
   </session>
489 489
 </iq>
490
-      ]]></example>
490
+]]></example>
491 491
 
492 492
       <p>One or more &lt;item type="connection" action="confirm/&gt; elements, each specifying a JID to accept/reject. To accept (or reject) a connection, the sender responds with an "iq-result", wrapping each JID in either an &lt;item type="connection" action="accept"/&gt; or &lt;item type="connection" action="reject"/&gt;.</p>
493 493
 
@@ -499,7 +499,7 @@ confirm: SID00001234
499 499
     <item type='connection' action='accept'>receiver@domain/res</item>
500 500
   </session>
501 501
 </iq>
502
-      ]]></example>
502
+]]></example>
503 503
       <example caption='Confirmation result (reject)'><![CDATA[
504 504
 <iq id='JOBS5' type='result' to='jobs.domain'>
505 505
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -508,7 +508,7 @@ confirm: SID00001234
508 508
     <item type='connection' action='reject'>receiver@domain/res</item>
509 509
   </session>
510 510
 </iq>
511
-      ]]></example>
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>
@@ -523,7 +523,7 @@ confirm: SID00001234
523 523
     <item type='connection' action='drop'>receiver@domain/res</item>
524 524
   </session>
525 525
 </iq>
526
-      ]]></example>
526
+]]></example>
527 527
 
528 528
       <p>If the connection is successfully dropped, the service returns an "iq-result":</p>
529 529
 
@@ -533,7 +533,7 @@ confirm: SID00001234
533 533
       status='active'
534 534
       id='01234567'/>
535 535
 </iq>
536
-      ]]></example>
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>
@@ -553,14 +553,14 @@ confirm: SID00001234
553 553
   <session xmlns='http://jabber.org/protocol/jobs'
554 554
       action='delete'/>
555 555
 </iq>
556
-      ]]></example>
556
+]]></example>
557 557
       <example caption='Delete result'><![CDATA[
558 558
 <iq id='JOBS50' type='result' to='sender@domain/res' from='jobs.domain'>
559 559
   <session xmlns='http://jabber.org/protocol/jobs'
560 560
       status='closed'
561 561
       id='01234567'/>
562 562
 </iq>
563
-      ]]></example>
563
+]]></example>
564 564
     </section3>
565 565
   </section2>
566 566
   <section2 topic='Being Notified about Events'>
@@ -576,7 +576,7 @@ confirm: SID00001234
576 576
     <item type='connection' action='accept'/>
577 577
   </session>
578 578
 </message>
579
-      ]]></example>
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>
@@ -592,7 +592,7 @@ confirm: SID00001234
592 592
     <item type='connection' action='reject'/>
593 593
   </session>
594 594
 </message>
595
-      ]]></example>
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>
@@ -608,7 +608,7 @@ confirm: SID00001234
608 608
     <item type='connection' action='drop'/>
609 609
   </session>
610 610
 </message>
611
-      ]]></example>
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>
@@ -624,7 +624,7 @@ confirm: SID00001234
624 624
     <item type='status' action='delete'/>
625 625
   </session>
626 626
 </message>
627
-      ]]></example>
627
+]]></example>
628 628
 
629 629
       <example caption='"Session Deleted (timed out)" message'><![CDATA[
630 630
 <message to='sender@domain/res' from='jobs.domain'>
@@ -635,7 +635,7 @@ confirm: SID00001234
635 635
     <item type='status' action='expire'/>
636 636
   </session>
637 637
 </message>
638
-      ]]></example>
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>
@@ -676,7 +676,7 @@ confirm: SID00001234
676 676
     max     CDATA #REQUIRED
677 677
     min     CDATA #REQUIRED
678 678
 >
679
-      ]]></code>
679
+]]></code>
680 680
     </section3>
681 681
     <section3 topic='&lt;session/&gt; Element'>
682 682
       <p>The &lt;session/&gt; element is the core element to the protocol. This element provides both information about a session and the action applied to it. It has a large number of attributes, and contains zero or more &lt;item/&gt; elements, zero or more &lt;connect/&gt; elements, and zero or three &lt;limit/&gt; elements. It may also contain elements governed by other namespaces.</p>
@@ -1009,7 +1009,7 @@ SP :=               <US-ASCII SP, space (32)>
1009 1009
 CR :=               <US-ASCII CR, carriage return (13)>
1010 1010
 LF :=               <US-ASCII LF, linefeed (10)>
1011 1011
 BINDATA :=          <Arbitrary Binary Data>
1012
-      ]]></code></section3>
1012
+]]></code></section3>
1013 1013
     <section3 topic='State Details'>
1014 1014
       <table caption='"init" details'>
1015 1015
         <tr>

+ 12
- 12
xep-0047.xml View File

@@ -133,14 +133,14 @@
133 133
         sid='i781hf64'
134 134
         stanza='iq'/>
135 135
 </iq>
136
-    ]]></example>
136
+]]></example>
137 137
     <p>If the responder wishes to proceed with the IBB session, it returns an IQ-result to the initiator.</p>
138 138
     <example caption='Responder accepts session'><![CDATA[
139 139
 <iq from='juliet@capulet.com/balcony'
140 140
     id='jn3h8g65'
141 141
     to='romeo@montague.net/orchard'
142 142
     type='result'/>
143
-    ]]></example>
143
+]]></example>
144 144
     <p>If the responder does not support IBB, it returns a &unavailable; or &feature; error.</p>
145 145
     <example caption='Responder does not support IBB'><![CDATA[
146 146
 <iq from='juliet@capulet.com/balcony'
@@ -151,7 +151,7 @@
151 151
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
152 152
   </error>
153 153
 </iq>
154
-    ]]></example>
154
+]]></example>
155 155
     <p>If the responder supports IBB but would prefer a smaller block-size, it returns a &constraint; error.</p>
156 156
     <example caption='Responder prefers smaller chunks'><![CDATA[
157 157
 <iq from='juliet@capulet.com/balcony'
@@ -162,7 +162,7 @@
162 162
     <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
163 163
   </error>
164 164
 </iq>
165
-    ]]></example>
165
+]]></example>
166 166
     <p>If the responder supports IBB but does not wish to proceed with the session, it returns a &notacceptable; error.</p>
167 167
     <example caption='Responder does not wish to proceed'><![CDATA[
168 168
 <iq from='juliet@capulet.com/balcony'
@@ -173,7 +173,7 @@
173 173
     <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
174 174
   </error>
175 175
 </iq>
176
-    ]]></example>
176
+]]></example>
177 177
   </section2>
178 178
 
179 179
   <section2 topic='Sending Data' anchor='send'>
@@ -192,7 +192,7 @@
192 192
     kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
193 193
   </data>
194 194
 </iq>
195
-    ]]></example>
195
+]]></example>
196 196
     <p>Each chunk of data is included as the XML character data of the &lt;data/&gt; element after being encoded as Base64 as specified in Section 4 of &rfc4648;. Each block MUST be a valid base64 block with padding at the end if needed.</p>
197 197
     <p>The &lt;data/&gt; element MUST possess a 'seq' attribute; this is a 16-bit unsigned integer that acts as a counter for data chunks sent in a particular direction within this session. The 'seq' value starts at 0 (zero) for each sender and MUST be incremented for each packet sent by that entity. Thus, the second chunk sent has a 'seq' value of 1, the third chunk has a 'seq' value of 2, and so on. The counter loops at maximum, so that after value 65535 (2<span class='super'>15</span> - 1) the 'seq' MUST start again at 0.</p>
198 198
     <p>The &lt;data/&gt; element MUST also possess a 'sid' attribute that ties the data chunk to this particular IBB session.</p>
@@ -202,7 +202,7 @@
202 202
     id='kr91n475'
203 203
     to='romeo@montague.net/orchard'
204 204
     type='result'/>
205
-    ]]></example>
205
+]]></example>
206 206
     <p>The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling.</p>
207 207
     <p>It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error:</p>
208 208
     <ol>
@@ -229,14 +229,14 @@
229 229
     type='set'>
230 230
   <close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/>
231 231
 </iq>
232
-    ]]></example>
232
+]]></example>
233 233
     <p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original &lt;close/&gt; element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).</p>
234 234
     <example caption='Success response'><![CDATA[
235 235
 <iq from='juliet@capulet.com/balcony'
236 236
     id='us71g45j'
237 237
     to='romeo@montague.net/orchard'
238 238
     type='result'/>
239
-    ]]></example>
239
+]]></example>
240 240
     <p>It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an &notfound; error.</p>
241 241
     <example caption='Recipient does not know about the IBB session'><![CDATA[
242 242
 <iq type='error'
@@ -247,7 +247,7 @@
247 247
     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
248 248
   </error>
249 249
 </iq>
250
-    ]]></example>
250
+]]></example>
251 251
     <p>In either case, both parties MUST consider the bytestream to be closed.</p>
252 252
   </section2>
253 253
 
@@ -271,7 +271,7 @@
271 271
     kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
272 272
   </data>
273 273
 </message>
274
-    ]]></example>
274
+]]></example>
275 275
 </section1>
276 276
 
277 277
 <section1 topic='Usage Guidelines' anchor='usage'>
@@ -362,7 +362,7 @@
362 362
   </xs:simpleType>
363 363
 
364 364
 </xs:schema>
365
-  ]]></code>
365
+]]></code>
366 366
 </section1>
367 367
 
368 368
 <section1 topic='Acknowledgements' anchor='ack'>

+ 8
- 8
xep-0048.xml View File

@@ -120,7 +120,7 @@
120 120
         <nick>Puck</nick>
121 121
       </conference>
122 122
     </storage>
123
-    ]]></example>
123
+]]></example>
124 124
    <p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p>
125 125
    <p>Note: A bookmark set may contain any number of conference rooms.</p>
126 126
   </section2>
@@ -152,7 +152,7 @@
152 152
       <url name='Complete Works of Shakespeare'
153 153
            url='http://the-tech.mit.edu/Shakespeare/'/>
154 154
     </storage>
155
-    ]]></example>
155
+]]></example>
156 156
     <p>This bookmark would be displayed in the client as 'Complete Works of Shakespeare' and would take the user to &lt;<link url='http://the-tech.mit.edu/Shakespeare/'>http://the-tech.mit.edu/Shakespeare/</link>&gt; when selected.</p>
157 157
     <p>Note: A bookmark set can contain any number of URLs.</p>
158 158
   </section2>
@@ -191,10 +191,10 @@
191 191
     </publish-options>
192 192
   </pubsub>
193 193
 </iq>
194
-    ]]></example>
194
+]]></example>
195 195
     <example caption='Server acknowledges successful storage'><![CDATA[
196 196
 <iq to='juliet@capulet.lit/balcony' type='result' id='pip1'/>
197
-    ]]></example>
197
+]]></example>
198 198
   </section2>
199 199
   <section2 topic='Receiving Notifications' anchor='storage-pubsub-notify'>
200 200
     <p>The stored data is automatically pushed to all of the user's connected resources.</p>
@@ -236,7 +236,7 @@
236 236
     </items>
237 237
   </event>
238 238
 </message>
239
-    ]]></example>
239
+]]></example>
240 240
   </section2>
241 241
   <section2 topic='Retrieving Data' anchor='storage-pubsub-retrieve'>
242 242
     <p>In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in <cite>XEP-0060</cite>.</p>
@@ -246,7 +246,7 @@
246 246
     <items node='storage:bookmarks'/>
247 247
   </pubsub>
248 248
 </iq>
249
-    ]]></example>
249
+]]></example>
250 250
     <example caption='Server returns all items'><![CDATA[
251 251
 <iq type='result'
252 252
     to='juliet@capulet.lit/randomID'
@@ -265,7 +265,7 @@
265 265
     </items>
266 266
   </pubsub>
267 267
 </iq>
268
-    ]]></example>
268
+]]></example>
269 269
   </section2>
270 270
 </section1>
271 271
 
@@ -338,7 +338,7 @@
338 338
   </xs:simpleType>
339 339
 
340 340
 </xs:schema>
341
-  ]]></code>
341
+]]></code>
342 342
 </section1>
343 343
 
344 344
 <section1 topic='Author Note' anchor='authornote'>

+ 6
- 6
xep-0049.xml View File

@@ -112,7 +112,7 @@ SERVER:
112 112
     from="hamlet@shakespeare.lit/denmark"
113 113
     to="hamlet@shakespeare.lit/denmark"
114 114
     id="1001"/>
115
-    ]]></example>
115
+]]></example>
116 116
 
117 117
     <example caption='Client Retrieves Private Data'><![CDATA[
118 118
 CLIENT:
@@ -133,7 +133,7 @@ SERVER:
133 133
     </exodus>
134 134
   </query>
135 135
 </iq>
136
-    ]]></example>
136
+]]></example>
137 137
 
138 138
     <p>If a user attempts to get or set jabber:iq:private data that belongs to another user, the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable).</p>
139 139
     <example caption='User Attempts to Get or Set Data for Another User'><![CDATA[
@@ -161,7 +161,7 @@ SERVER:
161 161
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
162 162
   </error>
163 163
 </iq>
164
-    ]]></example>
164
+]]></example>
165 165
     <p>If a user attempts to perform an IQ get without providing a child element, the server SHOULD return a "Bad Format" error (however, some existing implementations return a "Not Acceptable" error in such circumstances):</p>
166 166
     <example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[
167 167
 CLIENT:
@@ -177,7 +177,7 @@ SERVER:
177 177
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
178 178
   </error>
179 179
 </iq>
180
-    ]]></example>
180
+]]></example>
181 181
     <p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. Such behavior is OPTIONAL, but may be encountered by clients when interacting with some existing server implementations.</p>
182 182
     <example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[
183 183
 CLIENT:
@@ -201,7 +201,7 @@ SERVER (optional error):
201 201
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
202 202
   </error>
203 203
 </iq>
204
-    ]]></example>
204
+]]></example>
205 205
   </section2>
206 206
 </section1>
207 207
 <section1 topic='Error Conditions'>
@@ -247,6 +247,6 @@ SERVER (optional error):
247 247
   </xs:element>
248 248
 
249 249
 </xs:schema>
250
-    ]]></code>
250
+]]></code>
251 251
 </section1>
252 252
 </xep>

+ 28
- 28
xep-0050.xml View File

@@ -169,7 +169,7 @@
169 169
     from='requester@domain'>
170 170
   <query xmlns='http://jabber.org/protocol/disco#info'/>
171 171
 </iq>
172
-    ]]></example>
172
+]]></example>
173 173
     <example caption='Disco result for information'><![CDATA[
174 174
 <iq type='result'
175 175
     from='responder@domain'
@@ -180,7 +180,7 @@
180 180
     ...
181 181
   </query>
182 182
 </iq>
183
-    ]]></example>
183
+]]></example>
184 184
   </section2>
185 185
   <section2 topic='Retrieving the Command List' anchor='retrieve'>
186 186
     <p>To find what commands an entity provides, the requester uses Service Discovery. Each command is a node of the responder, under the fixed node "http://jabber.org/protocol/commands" (for which the service discovery identity category is "automation" and type is "command-list"). Use of a fixed node for all commands of an entity allows for immediate retrieval of commands.</p>
@@ -193,7 +193,7 @@
193 193
   <query xmlns='http://jabber.org/protocol/disco#items'
194 194
          node='http://jabber.org/protocol/commands'/>
195 195
 </iq>
196
-    ]]></example>
196
+]]></example>
197 197
     <example caption='Disco result for items'><![CDATA[
198 198
 <iq type='result'
199 199
     to='requester@domain'
@@ -220,7 +220,7 @@
220 220
           name='Restart Service'/>
221 221
   </query>
222 222
 </iq>
223
-    ]]></example>
223
+]]></example>
224 224
     <p>The result can then be used by the client to populate a menu, a dialog of buttons, or whatever is appropriate to the current user interface. The responder is not required to send the same list of commands to all requesters.</p>
225 225
     <p>If additional information about a command is desired, the requester queries for disco information on the command node:</p>
226 226
     <example caption='Disco request for command information'><![CDATA[
@@ -230,7 +230,7 @@
230 230
   <query xmlns='http://jabber.org/protocol/disco#info'
231 231
          node='config'/>
232 232
 </iq>
233
-    ]]></example>
233
+]]></example>
234 234
     <example caption='Disco result for command information'><![CDATA[
235 235
 <iq type='result'
236 236
     to='requester@domain'
@@ -244,7 +244,7 @@
244 244
     <feature var='jabber:x:data'/>
245 245
   </query>
246 246
 </iq>
247
-    ]]></example>
247
+]]></example>
248 248
     <p>A responder MUST at least provide &lt;identity category='automation' type='command-node'/&gt; and &lt;feature var='http://jabber.org/protocol/commands'/&gt;, and SHOULD include &lt;feature var='jabber:x:data'/&gt;. It is not required to support additional information about a command. If the command is not available to the requester, the responder SHOULD respond with a 403 "Forbidden" error.</p>
249 249
   </section2>
250 250
   <section2 topic='Announcing the Command List' anchor='announce'>
@@ -274,7 +274,7 @@
274 274
           name='Restart Service'/>
275 275
   </query>
276 276
 </message>
277
-    ]]></example>
277
+]]></example>
278 278
     <p>The only portion required is &lt;query xmlns='http://jabber.org/protocol/disco#items'/&gt;. Any other information (such as the &lt;subject/&gt; in the foregoing example) is OPTIONAL.</p>
279 279
   </section2>
280 280
   <section2 topic='Executing Commands' anchor='execute'>
@@ -286,7 +286,7 @@
286 286
            node='list'
287 287
            action='execute'/>
288 288
 </iq>
289
-      ]]></example>
289
+]]></example>
290 290
     <p>The requester MAY include the "action='execute'", although this is implied.</p>
291 291
     <p>If the command does not require any user interaction (returns results only), the responder sends a packet similar to the following:</p>
292 292
     <example caption="Execute command result"><![CDATA[
@@ -328,7 +328,7 @@
328 328
     </x>