Browse Source

Fix DTD check for 0017–0058

Sam Whited 2 years ago
parent
commit
4f89d9467c
18 changed files with 202 additions and 154 deletions
  1. 4
    0
      xep-0017.xml
  2. 2
    2
      xep-0035.xml
  3. 2
    1
      xep-0036.xml
  4. 4
    0
      xep-0037.xml
  5. 36
    37
      xep-0038.xml
  6. 59
    56
      xep-0039.xml
  7. 1
    1
      xep-0040.xml
  8. 35
    31
      xep-0041.xml
  9. 6
    2
      xep-0042.xml
  10. 4
    3
      xep-0043.xml
  11. 4
    2
      xep-0044.xml
  12. 1
    1
      xep-0046.xml
  13. 2
    2
      xep-0047.xml
  14. 4
    0
      xep-0051.xml
  15. 11
    2
      xep-0052.xml
  16. 4
    1
      xep-0056.xml
  17. 9
    8
      xep-0057.xml
  18. 14
    5
      xep-0058.xml

+ 4
- 0
xep-0017.xml View File

@@ -13,6 +13,10 @@
13 13
 <status>Rejected</status>
14 14
 <type>Informational</type>
15 15
 <sig>Standards</sig>
16
+<dependencies/>
17
+<supersedes/>
18
+<supersededby/>
19
+<shortname>N/A</shortname>
16 20
 <author>
17 21
 <firstname>Mike</firstname>
18 22
 <surname>Lin</surname>

+ 2
- 2
xep-0035.xml View File

@@ -17,7 +17,7 @@
17 17
   <sig>Standards</sig>
18 18
   <dependencies/>
19 19
   <supersedes/>
20
-  <supersededby>XMPP Core</supersededby>
20
+  <supersededby><spec>XMPP Core</spec></supersededby>
21 21
   <shortname>N/A</shortname>
22 22
   <author>
23 23
     <firstname>Robert</firstname>
@@ -29,7 +29,7 @@
29 29
     <version>0.2</version>
30 30
     <date>2003-11-05</date>
31 31
     <initials>psa</initials>
32
-    <remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;.</remark>
32
+    <remark>The status of this specification has been changed to Retracted since it has been superseded by XMPP Core.</remark>
33 33
   </revision>
34 34
   <revision>
35 35
     <version>0.1</version>

+ 2
- 1
xep-0036.xml View File

@@ -13,8 +13,9 @@
13 13
   <status>Retracted</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
+  <dependencies/>
16 17
   <supersedes/>
17
-  <supersededby>XEP-0060</supersededby>
18
+  <supersededby><spec>XEP-0060</spec></supersededby>
18 19
   <shortname>None</shortname>
19 20
   &pgmillard;
20 21
   &stpeter;

+ 4
- 0
xep-0037.xml View File

@@ -13,6 +13,10 @@
13 13
   <status>Rejected</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
+  <dependencies/>
17
+  <supersedes/>
18
+  <supersededby/>
19
+  <shortname>N/A</shortname>
16 20
   <author>
17 21
     <firstname>David</firstname>
18 22
     <surname>Sutton</surname>

+ 36
- 37
xep-0038.xml View File

@@ -17,7 +17,6 @@
17 17
   <supersedes/>
18 18
   <supersededby/>
19 19
   <shortname>None</shortname>
20
-  <schemaloc>Not yet assigned</schemaloc>
21 20
   <author>
22 21
     <firstname>Adam</firstname>
23 22
     <surname>Theo</surname>
@@ -66,13 +65,13 @@
66 65
 <section1 topic='Requirements'>
67 66
   <p>The following issues must be solved for in this specification.</p>
68 67
   <ul>
69
-    <li><b>Here and Now</b>: The convention should not rely on technologies such as feature negotiation or generic pub/sub which do not exist yet in Jabber in order to work properly. The convention should be a "here and now" solution, relying only on the current Jabber protocol.</li>
70
-    <li><b>Meaningful</b>: The convention for creating the icons must be meaningful to users of clients without icon support, or even users on the other side of transports. Whatever method is used, it should not be cryptic or difficult to understand in text-only mode, in case the user does not have or want the capability to view the icons.</li>
71
-    <li><b>Component Friendly</b>: In order for gateways, bots, and other "semi-intelligent" components to be able to convert or otherwise use the specification (such as to and from the MSN icon style, or use icons in conversations with Artificially Intelligent bots), a specific list of icons must be possible. Since these bots do not have an intelligent human behind them deciding their every action, they cannot deal with unlimited possibilities.</li>
72
-    <li><b>Protect Privacy</b>: Sender-defined external data must not be required to properly display the icons because it can be used by the sender to track the user, circumventing their privacy. When the sender can define their own graphics or sounds to be used for the icons, they can use unique URLs and monitor when these unique URLs are accessed. External data may be allowed as long as it is not required for proper use of the icons, but it would be best to leave external data completely out of the system.</li>
73
-    <li><b>Conserve Bandwidth</b>: The amount of markup used within the messages to define the icons should be kept to a minimum, as well as keeping the media files used for the icons from being transferred over the wire with the messages themselves. These easily consume too much bandwidth, a precious resource to most of the Internet.</li>
74
-    <li><b>Be Passive</b>: The convention should not force transports or recipients to take any action to properly display the icons. Not only does it put extra strain on the components, but it would also unnecessarily break old clients. Transports and recieving clients may have the option of taking some actions, but they should not be forced to.</li>
75
-    <li><b>Internationalization</b>: The convention must be inherently international in order to ease adoption of Jabber throughout the world and prevent later growing pains. The use of English must be kept to a minimum, restricted to "meta information" about the icons themselves, and must dynamically allow for non-English language sets.</li>
68
+    <li><strong>Here and Now</strong>: The convention should not rely on technologies such as feature negotiation or generic pub/sub which do not exist yet in Jabber in order to work properly. The convention should be a "here and now" solution, relying only on the current Jabber protocol.</li>
69
+    <li><strong>Meaningful</strong>: The convention for creating the icons must be meaningful to users of clients without icon support, or even users on the other side of transports. Whatever method is used, it should not be cryptic or difficult to understand in text-only mode, in case the user does not have or want the capability to view the icons.</li>
70
+    <li><strong>Component Friendly</strong>: In order for gateways, bots, and other "semi-intelligent" components to be able to convert or otherwise use the specification (such as to and from the MSN icon style, or use icons in conversations with Artificially Intelligent bots), a specific list of icons must be possible. Since these bots do not have an intelligent human behind them deciding their every action, they cannot deal with unlimited possibilities.</li>
71
+    <li><strong>Protect Privacy</strong>: Sender-defined external data must not be required to properly display the icons because it can be used by the sender to track the user, circumventing their privacy. When the sender can define their own graphics or sounds to be used for the icons, they can use unique URLs and monitor when these unique URLs are accessed. External data may be allowed as long as it is not required for proper use of the icons, but it would be best to leave external data completely out of the system.</li>
72
+    <li><strong>Conserve Bandwidth</strong>: The amount of markup used within the messages to define the icons should be kept to a minimum, as well as keeping the media files used for the icons from being transferred over the wire with the messages themselves. These easily consume too much bandwidth, a precious resource to most of the Internet.</li>
73
+    <li><strong>Be Passive</strong>: The convention should not force transports or recipients to take any action to properly display the icons. Not only does it put extra strain on the components, but it would also unnecessarily break old clients. Transports and recieving clients may have the option of taking some actions, but they should not be forced to.</li>
74
+    <li><strong>Internationalization</strong>: The convention must be inherently international in order to ease adoption of Jabber throughout the world and prevent later growing pains. The use of English must be kept to a minimum, restricted to "meta information" about the icons themselves, and must dynamically allow for non-English language sets.</li>
76 75
   </ul>
77 76
   <p>Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not allow external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components.</p>
78 77
 </section1>
@@ -92,12 +91,12 @@
92 91
   <section2 topic="Meta Elements">
93 92
     <p>The meta elements contain information about the Icon Style itself, rather that the individual icons. They are contained within the <tt>&lt;meta&gt;</tt> element, which is directly under the root element. There is one and only one the <tt>&lt;meta&gt;</tt> element.</p>
94 93
     <ul>
95
-      <li><b>Name</b>: This is an arbitrary text string (spaces allowed) which is the full name of the Icon Style. Only one name can be included.</li>
96
-      <li><b>Version</b>: This is an arbitrary text string (no spaces allowed) which is the version number of the Icon Style. Any version format is allowed, but the <tt>major.minor</tt> or <tt>major.minor.trivial</tt> formats are recommended. Only one version can be included.</li>
97
-      <li><b>Description</b>: This is the full description of the Icon Style. It summarizes the look and types of the icons, and can be used for keywords in searching. This is optional, but recommended.</li>
98
-      <li><b>Author</b>: This is the full name of the author. Multiple authors are allowed.</li>
99
-      <li><b>Creation</b>: This is the date of the creation of this version of the Icon Style. The date is in the <link url="http://www.w3.org/TR/NOTE-datetime">ISO 8601</link> standard format.</li>
100
-      <li><b>Home</b>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li>
94
+      <li><strong>Name</strong>: This is an arbitrary text string (spaces allowed) which is the full name of the Icon Style. Only one name can be included.</li>
95
+      <li><strong>Version</strong>: This is an arbitrary text string (no spaces allowed) which is the version number of the Icon Style. Any version format is allowed, but the <tt>major.minor</tt> or <tt>major.minor.trivial</tt> formats are recommended. Only one version can be included.</li>
96
+      <li><strong>Description</strong>: This is the full description of the Icon Style. It summarizes the look and types of the icons, and can be used for keywords in searching. This is optional, but recommended.</li>
97
+      <li><strong>Author</strong>: This is the full name of the author. Multiple authors are allowed.</li>
98
+      <li><strong>Creation</strong>: This is the date of the creation of this version of the Icon Style. The date is in the <link url="http://www.w3.org/TR/NOTE-datetime">ISO 8601</link> standard format.</li>
99
+      <li><strong>Home</strong>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li>
101 100
     </ul>
102 101
   </section2>
103 102
 
@@ -196,29 +195,29 @@
196 195
   <section2 topic='Core Icons'>
197 196
     <p>Although any text string can be turned into an icon by defining it in an <tt>icondef.xml</tt> file, it is highly reccomended they either follow traditional ASCII Art (smileys and frownys, for example) or full keywords in simple markup such as double-colons. If you want to design icons, always keep in mind that not every Jabber user uses graphics to "translate" this to something visual, as explained in the "Meaningful" requirement, above. Here is a short list of recommended "core" icons that should be in most definitions, as well as possibly be used by transports:</p>
198 197
     <ul>
199
-      <li><b>:-)</b> and <b>:)</b> - A smiling face.</li>
200
-      <li><b>:-(</b> and <b>:(</b> - A frowing face.</li>
201
-      <li><b>;-)</b> and <b>;)</b> - A winking smiling face.</li>
202
-      <li><b>:'-(</b> and <b>:'(</b> - A crying face.</li>
203
-      <li><b>>:-(</b> and <b>>:(</b> - An angry face.</li>
204
-      <li><b>:yes:</b> - A thumbs-up or checkmark.</li>
205
-      <li><b>:no:</b> - A thumbs-down or a crossmark.</li>
206
-      <li><b>:wait:</b> - An open hand, palm outstretched.</li>
207
-      <li><b>@->--</b> and <b>:rose:</b> - A rose flower.</li>
208
-      <li><b>:telephone:</b> - A telephone.</li>
209
-      <li><b>:email:</b> - An electronic-looking envelope.</li>
210
-      <li><b>:jabber:</b> - Jabber's lightbulb logo.</li>
211
-      <li><b>:cake:</b> - A birthday cake.</li>
212
-      <li><b>:kiss:</b> - A pair of puckered lips.</li>
213
-      <li><b>:heart:</b> and <b>:love:</b> - A heart.</li>
214
-      <li><b>:brokenheart:</b> - A broken heart.</li>
215
-      <li><b>:music:</b> - A musical note or instrument.</li>
216
-      <li><b>:beer:</b> - A beer mug.</li>
217
-      <li><b>:coffee:</b> - A cup of coffee.</li>
218
-      <li><b>:money:</b> - A gold coin.</li>
219
-      <li><b>:moon:</b> - A moon.</li>
220
-      <li><b>:sun:</b> - A sun.</li>
221
-      <li><b>:star:</b> - A star.</li>
198
+      <li><strong>:-)</strong> and <strong>:)</strong> - A smiling face.</li>
199
+      <li><strong>:-(</strong> and <strong>:(</strong> - A frowing face.</li>
200
+      <li><strong>;-)</strong> and <strong>;)</strong> - A winking smiling face.</li>
201
+      <li><strong>:'-(</strong> and <strong>:'(</strong> - A crying face.</li>
202
+      <li><strong>>:-(</strong> and <strong>>:(</strong> - An angry face.</li>
203
+      <li><strong>:yes:</strong> - A thumbs-up or checkmark.</li>
204
+      <li><strong>:no:</strong> - A thumbs-down or a crossmark.</li>
205
+      <li><strong>:wait:</strong> - An open hand, palm outstretched.</li>
206
+      <li><strong>@->--</strong> and <strong>:rose:</strong> - A rose flower.</li>
207
+      <li><strong>:telephone:</strong> - A telephone.</li>
208
+      <li><strong>:email:</strong> - An electronic-looking envelope.</li>
209
+      <li><strong>:jabber:</strong> - Jabber's lightbulb logo.</li>
210
+      <li><strong>:cake:</strong> - A birthday cake.</li>
211
+      <li><strong>:kiss:</strong> - A pair of puckered lips.</li>
212
+      <li><strong>:heart:</strong> and <strong>:love:</strong> - A heart.</li>
213
+      <li><strong>:brokenheart:</strong> - A broken heart.</li>
214
+      <li><strong>:music:</strong> - A musical note or instrument.</li>
215
+      <li><strong>:beer:</strong> - A beer mug.</li>
216
+      <li><strong>:coffee:</strong> - A cup of coffee.</li>
217
+      <li><strong>:money:</strong> - A gold coin.</li>
218
+      <li><strong>:moon:</strong> - A moon.</li>
219
+      <li><strong>:sun:</strong> - A sun.</li>
220
+      <li><strong>:star:</strong> - A star.</li>
222 221
     </ul>
223 222
   </section2>
224 223
 </section1>

+ 59
- 56
xep-0039.xml View File

@@ -13,6 +13,10 @@
13 13
     <status>Deferred</status>
14 14
     <type>Standards Track</type>
15 15
     <sig>Standards</sig>
16
+    <dependencies><spec>XEP-0053</spec></dependencies>
17
+    <supersedes/>
18
+    <supersededby/>
19
+    <shortname>N/A</shortname>
16 20
     <author>
17 21
       <firstname>Paul</firstname>
18 22
       <surname>Curtis</surname>
@@ -21,7 +25,7 @@
21 25
     </author>
22 26
     <author>
23 27
       <firstname>Russell</firstname>
24
-      <surname>Davis</surname>  
28
+      <surname>Davis</surname>
25 29
       <email>ukscone@burninghorse.com</email>
26 30
       <jid>ukscone@burninghorse.com</jid>
27 31
     </author>
@@ -41,41 +45,44 @@
41 45
       <version>0.6.0</version>
42 46
       <date>2002-11-05</date>
43 47
       <initials>rkd</initials>
44
-      <remark>Corrected David Sutton's JID and email. It has been pointed out
45
-	to me by amoungst others Rob Norris that things such as lists of JIDs 
46
-	and lists in general are really the province of disco and browse and 
47
-	that at least one of the suggested 'core' statistics doesn't 
48
-	make sense for all components so removed these from the document. This namespace
49
-	was starting to become a generic data gathering namespace and we already 
50
-	have one of those, so i've reworked yet again hopefully for the 
51
-	final time it should now be simpler to implement and more consistent in
52
-	all cases.</remark>
53
-    </revision>    
48
+      <remark>
49
+        Corrected David Sutton's JID and email.
50
+        It has been pointed out to me by amoungst others Rob Norris that things
51
+        such as lists of JIDs and lists in general are really the province of
52
+        disco and browse and that at least one of the suggested 'core'
53
+        statistics doesn't make sense for all components so removed these from
54
+        the document.
55
+        This namespace was starting to become a generic data gathering namespace
56
+        and we already have one of those, so I've reworked yet again hopefully
57
+        for the final time it should now be simpler to implement and more
58
+        consistent in all cases.
59
+      </remark>
60
+    </revision>
54 61
     <revision>
55 62
       <version>0.5.0</version>
56 63
       <date>2002-11-03</date>
57 64
       <initials>rkd</initials>
58 65
       <remark>Heavily modified document according to suggestions from Matt Miller (linuxwolf). rkd had some additional thoughts on the name attribute, this version reflects those. Reorganized the description section.</remark>
59
-    </revision>    
66
+    </revision>
60 67
     <revision>
61 68
       <version>0.4.2</version>
62 69
       <date>2002-10-25</date>
63 70
       <initials>rkd</initials>
64 71
       <remark>Changed rkd's email address and jid. Modified namespace to use http uri.</remark>
65
-    </revision>    
72
+    </revision>
66 73
     <revision>
67 74
       <version>0.4.1</version>
68 75
       <date>2002-08-20</date>
69 76
       <initials>rkd</initials>
70 77
       <remark>Corrected error codes</remark>
71
-    </revision>    
78
+    </revision>
72 79
     <revision>
73 80
       <version>0.4</version>
74 81
       <date>2002-08-18</date>
75 82
       <initials>rkd</initials>
76 83
       <remark>Fixed two silly typos that crept back in. Rewrote SNMP
77 84
       to read better. Added the DTD</remark>
78
-    </revision>    
85
+    </revision>
79 86
     <revision>
80 87
       <version>0.3</version>
81 88
       <date>2002-08-16</date>
@@ -83,9 +90,9 @@
83 90
       <remark>Added &lt;display/&gt; so a server or component may
84 91
       optionally return data in a human readable format. It is nothing
85 92
       more than a bit of visual fluff but it has potential to be quite
86
-      useful. Renumbered the revisions to allow room for stpeter's new 
87
-      document numbering scheme, sorry if it is now confusing but I hadn't 
88
-      left much room to grow with the previous revision numbering. A 
93
+      useful. Renumbered the revisions to allow room for stpeter's new
94
+      document numbering scheme, sorry if it is now confusing but I hadn't
95
+      left much room to grow with the previous revision numbering. A
89 96
       little more prettying and judicious use of punctuation has occurred.</remark>
90 97
     </revision>
91 98
     <revision>
@@ -99,7 +106,7 @@
99 106
       <date>2002-08-14</date>
100 107
       <initials>rkd</initials>
101 108
       <remark>I seem to have misunderstood one of Ryan Eatmon's
102
-      suggestions and didn't make this generic enough. I have  
109
+      suggestions and didn't make this generic enough. I have
103 110
       fixed that now. Clarified error codes and reworked how errors
104 111
       are indicated to work with the new generic
105 112
       namespace. Rearranged the order of the sections a bit make this
@@ -157,15 +164,14 @@
157 164
       <initials>rkd</initials>
158 165
       <remark>Initial version.</remark>
159 166
     </revision>
160
-    <dependencies>XEP-0053</dependencies>
161 167
   </header>
162 168
   <section1 topic='Introduction'>
163 169
     <p>As things currently stand it is not possible to obtain statistics
164
-    from a jabber component or server without resorting to parsing the 
165
-    various log files. This makes it extremely difficult to obtain statistics 
166
-    that are of any use in real world situations. This document attempts to 
167
-    rectify this situation by defining a new namespace that would be used 
168
-    to obtain statistics from a component or server so that they may be 
170
+    from a jabber component or server without resorting to parsing the
171
+    various log files. This makes it extremely difficult to obtain statistics
172
+    that are of any use in real world situations. This document attempts to
173
+    rectify this situation by defining a new namespace that would be used
174
+    to obtain statistics from a component or server so that they may be
169 175
     manipulated and used in a useful manner. For the purposes of this namespace
170 176
     a statistic is anything that maybe expressed in a numeric form, such as the
171 177
     uptime of a server, the <strong>number</strong> of registered users and the
@@ -182,7 +188,7 @@
182 188
         &lt;stat name='' units='' value=''/&gt;
183 189
       &lt;/query&gt;
184 190
       </code>
185
-      <p> There is one variation in the	case of an error invalidating one or 
191
+      <p> There is one variation in the	case of an error invalidating one or
186 192
 	more errors in a single returned query that does not actually
187 193
 	invalidate the whole query.</p>
188 194
       <code>
@@ -194,8 +200,8 @@
194 200
     <section2 topic='Name Attribute'>
195 201
       <p>The name of the statistic. The format for this attribute is the
196 202
 	generic statistic type such as bandwidth, users, time etc. followed by
197
-	a '/' character and then then the name of the actual statistic. For 
198
-	example bandwidth/packets-in, time/uptime and users/online. This will 
203
+	a '/' character and then then the name of the actual statistic. For
204
+	example bandwidth/packets-in, time/uptime and users/online. This will
199 205
 	be assigned and administered by JANA<note>See Name Registration</note>.</p>
200 206
     </section2>
201 207
     <section2 topic='Units Attribute'>
@@ -218,7 +224,6 @@
218 224
       send:     &lt;iq type='get' to='component'&gt;
219 225
 	          &lt;query xmlns='http://jabber.org/protocol/stats'/&gt;
220 226
                 &lt;/iq&gt;
221
-      
222 227
 
223 228
       recv:     &lt;iq type='result' from='component'&gt;
224 229
                   &lt;query xmlns='http://jabber.org/protocol/stats'&gt;
@@ -252,8 +257,8 @@
252 257
                   &lt;query xmlns='http://jabber.org/protocol/stats'&gt;
253 258
                     &lt;stat name='time/uptime' units='seconds'	value='3054635'/&gt;
254 259
 	            &lt;stat name='users/online' units='users' value='365'/&gt;
255
-	            &lt;stat name='bandwidth/packets-in' units='packets' value='23434'/&gt; 
256
-	            &lt;stat name='bandwidth/packets-out' units='packets' value='23422'/&gt;      
260
+	            &lt;stat name='bandwidth/packets-in' units='packets' value='23434'/&gt;
261
+	            &lt;stat name='bandwidth/packets-out' units='packets' value='23422'/&gt;
257 262
                   &lt;/query&gt;
258 263
                 &lt;/iq&gt;
259 264
       </example>
@@ -261,7 +266,7 @@
261 266
     </section2>
262 267
     <section2 topic='Errors'>
263 268
       <p>If an error occurs with one or more of the requests for
264
-      statistics the component or server should return one of the 
269
+      statistics the component or server should return one of the
265 270
       following error codes.</p>
266 271
       <table caption='Error Codes'>
267 272
         <tr><th>Code</th><th>String</th><th>Reason</th></tr>
@@ -274,17 +279,15 @@
274 279
         <tr><td>503</td><td>Service Unavailable</td><td>Statistic is
275 280
         temporarily unavailable</td></tr>
276 281
       </table>
277
-
278
-   
279 282
       <p>Because we wish to be able to collect groups of statistics
280 283
       within a single returned packet errors must be handled in a two
281
-      tier way with authorization and core errors that would render 
282
-      <strong>all</strong> the statistics meaningless being indicated 
284
+      tier way with authorization and core errors that would render
285
+      <strong>all</strong> the statistics meaningless being indicated
283 286
       with a type='error' in the returned packet.</p>
284 287
 
285 288
       <example>
286
-        &lt;iq type='error' from='component'&gt; 
287
-          &lt;query xmlns='http://jabber.org/protocol/stats'&gt;  
289
+        &lt;iq type='error' from='component'&gt;
290
+          &lt;query xmlns='http://jabber.org/protocol/stats'&gt;
288 291
             &lt;error code='401'&gt;Not Authorized&lt;/error&gt;
289 292
           &lt;/query&gt;
290 293
         &lt;/iq&gt;
@@ -310,12 +313,12 @@
310 313
     <section2 topic='Name Registration'>
311 314
       <p>All statistic names, returned data units types and other
312 315
 	pertinent statistic information will be assigned and registered with
313
-	the Jabber Naming Authority in the category <em><strong>stat</strong></em>. 
314
-	Unfortunately at this time such a body does not exist so we will 
316
+	the Jabber Naming Authority in the category <em><strong>stat</strong></em>
317
+	Unfortunately at this time such a body does not exist so we will
315 318
 	have to rely on component and server authors diligently
316
-	researching to ensure that their desired name is not already 
319
+	researching to ensure that their desired name is not already
317 320
 	in use and that they adequately document the returned units
318
-	type and anything else that would normally be registered. 
321
+	type and anything else that would normally be registered.
319 322
 	Hopefully by the time this document is formally adopted
320 323
 	a central naming authority for the Jabber protocol will be in
321 324
 	place and functional and authors will be then able to register
@@ -386,16 +389,16 @@
386 389
     <section2 topic='SNMP'>
387 390
       <p>Supporting industry accepted standards and procedures
388 391
       <note>For more details on <link url='http://www.snmplink.org'>SNMP</link>
389
-      and <link url='http://www.dmtf.org'>CIM</link></note> within 
390
-      the Jabber protocol is highly desirable as long as it does not 
391
-      restrict the flexibility or functionality of Jabber. So while 
392
-      the <strong>http://jabber.org/protocol/stats</strong> namespace seems to fall within the domain of 
393
-      the SNMP and CIM standards amongst others and large jabber 
394
-      installations would find direct support an appealing prospect 
395
-      when tying jabber into their existing network information and 
396
-      management systems the jabber:iq:namespace will not do this. 
397
-      Because Jabber is an XML based protocol, conversion of 
398
-      the returned data to other formats including those required 
392
+      and <link url='http://www.dmtf.org'>CIM</link></note> within
393
+      the Jabber protocol is highly desirable as long as it does not
394
+      restrict the flexibility or functionality of Jabber. So while
395
+      the <strong>http://jabber.org/protocol/stats</strong> namespace seems to fall within the domain of
396
+      the SNMP and CIM standards amongst others and large jabber
397
+      installations would find direct support an appealing prospect
398
+      when tying jabber into their existing network information and
399
+      management systems the jabber:iq:namespace will not do this.
400
+      Because Jabber is an XML based protocol, conversion of
401
+      the returned data to other formats including those required
399 402
       for SNMP, CIM etc. should be relatively simple. Not supporting
400 403
       industry standards is not without advantages. By leaving the
401 404
       <strong>http://jabber.org/protocol/stats</strong> as a <em>pure</em> jabber namespace we allow
@@ -412,14 +415,14 @@
412 415
     </section2>
413 416
   </section1>
414 417
   <section1 topic='Realworld Examples'>
415
-      TBD
418
+    <p>TBD</p>
416 419
   </section1>
417 420
   <section1 topic='DTD'>
418 421
     <section2 topic='DTD in English'>
419
-      TBD
420
-    </section2>    
422
+      <p>TBD</p>
423
+    </section2>
421 424
     <section2 topic='DTD'>
422
-      TBD
425
+      <p>TBD</p>
423 426
     </section2>
424 427
   </section1>
425 428
 </xep>

+ 1
- 1
xep-0040.xml View File

@@ -15,7 +15,7 @@
15 15
       <sig>Standards</sig>
16 16
       <dependencies/>
17 17
       <supersedes/>
18
-      <supersededby>XEP-0060</supersededby>
18
+      <supersededby><spec>XEP-0060</spec></supersededby>
19 19
       <shortname>None</shortname>
20 20
       <author>
21 21
          <firstname>Tim</firstname>

+ 35
- 31
xep-0041.xml View File

@@ -13,9 +13,13 @@
13 13
   <status>Retracted</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>XMPP Core, XEP-0020, XEP-0030</dependencies>
16
+  <dependencies>
17
+    <spec>XMPP Core</spec>
18
+    <spec>XEP-0020</spec>
19
+    <spec>XEP-0030</spec>
20
+  </dependencies>
17 21
   <supersedes/>
18
-  <supersededby>XEP-0065</supersededby>
22
+  <supersededby><spec>XEP-0065</spec></supersededby>
19 23
   <shortname>rel</shortname>
20 24
   <author>
21 25
     <firstname>Justin</firstname>
@@ -27,7 +31,7 @@
27 31
     <version>0.2</version>
28 32
     <date>2003-09-30</date>
29 33
     <initials>psa</initials>
30
-    <remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;.</remark>
34
+    <remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by XEP-0065.</remark>
31 35
   </revision>
32 36
   <revision>
33 37
     <version>0.8</version>
@@ -87,36 +91,36 @@
87 91
 <p>A REL-compatible stream transport must have the following properties:</p>
88 92
 <ul>
89 93
   <li>Provides a reliable bytestream between two Jabber entities, which means that the bytestream transport handles all data delivery issues, such that the application need not worry about them.</li>
90
-  <li>Has a the following link states:
91
-    <table caption='Link states'>
92
-      <tr>
93
-        <th>Code</th>
94
-        <th>Description</th>
95
-      </tr>
96
-      <tr>
97
-        <td><tt>INIT</tt></td>
98
-        <td>Initiation</td>
99
-      </tr>
100
-      <tr>
101
-        <td><tt>GOOD</tt></td>
102
-        <td>Successful initiation (connected)</td>
103
-      </tr>
104
-      <tr>
105
-        <td><tt>BAD</tt></td>
106
-        <td>Unsuccessful initiation (stream is closed, no further state)</td>
107
-      </tr>
108
-      <tr>
109
-        <td><tt>CLOS</tt></td>
110
-        <td>Successful closure after establishment (stream is closed, no further state)</td>
111
-      </tr>
112
-      <tr>
113
-        <td><tt>ERR</tt></td>
114
-        <td>Link failure after establishment (stream is closed, no further state)</td>
115
-      </tr>
116
-    </table>
94
+  <li>Has link states from the following table.
117 95
   </li>
118 96
   <li>Defines a stream identifier, which MUST have a unique ASCII representation. The stream protocol MUST be able to use any ASCII identifier chosen during REL negotiation, as long as the sending party doesn't use the same identifier more than once.</li>
119 97
 </ul>
98
+<table caption='Link states'>
99
+  <tr>
100
+    <th>Code</th>
101
+    <th>Description</th>
102
+  </tr>
103
+  <tr>
104
+    <td><tt>INIT</tt></td>
105
+    <td>Initiation</td>
106
+  </tr>
107
+  <tr>
108
+    <td><tt>GOOD</tt></td>
109
+    <td>Successful initiation (connected)</td>
110
+  </tr>
111
+  <tr>
112
+    <td><tt>BAD</tt></td>
113
+    <td>Unsuccessful initiation (stream is closed, no further state)</td>
114
+  </tr>
115
+  <tr>
116
+    <td><tt>CLOS</tt></td>
117
+    <td>Successful closure after establishment (stream is closed, no further state)</td>
118
+  </tr>
119
+  <tr>
120
+    <td><tt>ERR</tt></td>
121
+    <td>Link failure after establishment (stream is closed, no further state)</td>
122
+  </tr>
123
+</table>
120 124
 <p>The following stream transports that meet these guidelines are:</p>
121 125
 <table caption='Supported streams'>
122 126
   <tr>
@@ -146,7 +150,7 @@
146 150
 </iq>
147 151
 ]]></example>
148 152
 
149
-The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.
153
+<p>The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.</p>
150 154
 
151 155
 <example caption='Response'><![CDATA[
152 156
 <iq type="result" from="joe@blow.com/Home" id="sd_1">

+ 6
- 2
xep-0042.xml View File

@@ -13,9 +13,13 @@
13 13
   <status>Retracted</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED)</dependencies>
16
+  <dependencies>
17
+    <spec>XEP-0004 (OPTIONAL)</spec>
18
+    <spec>XEP-0011 (RECOMMENDED)</spec>
19
+    <spec>XEP-0029 (REQUIRED)</spec>
20
+  </dependencies>
17 21
   <supersedes/>
18
-  <supersededby>XEP-0065</supersededby>
22
+  <supersededby><spec>XEP-0065</spec></supersededby>
19 23
   <shortname>JOBS</shortname>
20 24
   <author>
21 25
     <firstname>Matthew</firstname>

+ 4
- 3
xep-0043.xml View File

@@ -13,6 +13,10 @@
13 13
     <status>Retracted</status>
14 14
     <type>Standards Track</type>
15 15
     <sig>Standards</sig>
16
+    <dependencies/>
17
+    <supersedes/>
18
+    <supersededby/>
19
+    <shortname>N/A</shortname>
16 20
     <author>
17 21
       <firstname>Justin</firstname>
18 22
       <surname>Kirby</surname>
@@ -38,14 +42,11 @@
38 42
     Database API or query language. Instead, it will providing a
39 43
     simple mechanism for a JID to read/write data that it has access to 
40 44
     and specifying a model for those schemas to use in xml.</p>
41
-  
42 45
     <p>This document has two aims.</p>
43
-
44 46
     <ol>
45 47
       <li>Be able to request the available schemas</li>
46 48
       <li>Perform near SQL-like data manipulation</li>
47 49
     </ol>
48
-  
49 50
     <p>Although designed for use with an RDBMS this document is not
50 51
     restricted to such uses. It may be used with any data storage 
51 52
     system that can be broken down to a simple table, column/row 

+ 4
- 2
xep-0044.xml View File

@@ -15,6 +15,10 @@
15 15
   <status>Deferred</status>
16 16
   <type>Standards Track</type>
17 17
   <sig>Standards</sig>
18
+  <dependencies/>
19
+  <supersedes/>
20
+  <supersededby/>
21
+  <shortname>N/A</shortname>
18 22
   <author>
19 23
     <firstname>Robert</firstname>
20 24
     <surname>Norris</surname>
@@ -42,7 +46,6 @@
42 46
 <section1 topic='Requirements and Protocol'>
43 47
 
44 48
   <p>A typical XML stream is a pair of XML documents, one for each direction of communication between the two peers. An simple example of these might look like this:</p>
45
-  
46 49
   <example caption="A typical XML stream"><![CDATA[
47 50
 SEND: <stream:stream xmlns='jabber:client'
48 51
                      xmlns:stream='http://etherx.jabber.org/streams'
@@ -91,7 +94,6 @@ RECV: <iq type='result' from='jabber.org'>
91 94
   </example>
92 95
 
93 96
   <p>Currently, the prefix for each namespace is fixed; it cannot vary at all, since implementations use it for matching. The desire is to be able to use arbitrary prefixes:</p>
94
- 
95 97
   <example caption="XML stream with arbitrary namespace prefixes (1)"><![CDATA[
96 98
 SEND: <stream xmlns:app='jabber:client'
97 99
               xmlns='http://etherx.jabber.org/streams'

+ 1
- 1
xep-0046.xml View File

@@ -15,7 +15,7 @@
15 15
   <sig>Standards</sig>
16 16
   <dependencies/>
17 17
   <supersedes/>
18
-  <supersededby>XEP-0065</supersededby>
18
+  <supersededby><spec>XEP-0065</spec></supersededby>
19 19
   <shortname>None</shortname>
20 20
   <author>
21 21
     <firstname>Justin</firstname>

+ 2
- 2
xep-0047.xml View File

@@ -18,10 +18,10 @@
18 18
   </dependencies>
19 19
   <supersedes/>
20 20
   <supersededby/>
21
+  <shortname>ibb</shortname>
21 22
   <schemaloc>
22 23
     <url>http://www.xmpp.org/schemas/ibb.xsd</url>
23 24
   </schemaloc>
24
-  <shortname>ibb</shortname>
25 25
   &infiniti;
26 26
   &stpeter;
27 27
   <revision>
@@ -216,7 +216,7 @@
216 216
       <li>Because the sequence number has already been used, the recipient returns an &unexpected; error with a type of 'cancel'.</li>
217 217
       <li>Because the data is not formatted in accordance with Section 4 of <cite>RFC 4648</cite>, the recipient returns a &badrequest; error with a type of 'cancel'.</li>
218 218
     </ol>
219
-    <p>Upon receiving an error related to the data packet, the sender MUST close the bytestream as described under <link rel='#close'>Closing the Bytestream</link>.</p>
219
+    <p>Upon receiving an error related to the data packet, the sender MUST close the bytestream as described under <link url='#close'>Closing the Bytestream</link>.</p>
220 220
     <p>Data packets MUST be processed in the order they are received. If an out-of-sequence packet is received for a particular direction within a bytestream (determined by checking the 'seq' attribute), then this indicates that a packet has been lost. The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream; instead, the recipient MUST close the bytestream as described in the next section.</p>
221 221
   </section2>
222 222
 

+ 4
- 0
xep-0051.xml View File

@@ -13,6 +13,10 @@
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
+  <dependencies/>
17
+  <supersedes/>
18
+  <supersededby/>
19
+  <shortname>N/A</shortname>
16 20
   <author>
17 21
     <firstname>Klaus</firstname>
18 22
     <surname>Wolf</surname>

+ 11
- 2
xep-0052.xml View File

@@ -13,9 +13,18 @@
13 13
   <status>Retracted</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030</dependencies>
16
+  <dependencies>
17
+    <spec>XMPP Core</spec>
18
+    <spec>XMPP IM</spec>
19
+    <spec>XEP-0004</spec>
20
+    <spec>XEP-0020</spec>
21
+    <spec>XEP-0030</spec>
22
+  </dependencies>
17 23
   <supersedes/>
18
-  <supersededby>XEP-0095, XEP-0096</supersededby>
24
+  <supersededby>
25
+    <spec>XEP-0095</spec>
26
+    <spec>XEP-0096</spec>
27
+  </supersededby>
19 28
   <shortname>N/A</shortname>
20 29
   <author>
21 30
     <firstname>Thomas</firstname>

+ 4
- 1
xep-0056.xml View File

@@ -14,6 +14,9 @@
14 14
 <type>Standards Track</type>
15 15
 <sig>Standards</sig>
16 16
 <dependencies/>
17
+<supersedes/>
18
+<supersededby/>
19
+<shortname>N/A</shortname>
17 20
 <author>
18 21
 <firstname>Ulrich</firstname>
19 22
 <surname>Staudinger</surname>
@@ -159,7 +162,7 @@ EDIFACT/UN is very similar to X.12 and differs only in the meaning of tags and i
159 162
 
160 163
 <section1 topic='Transmitting SAP iDoc via XMPP'>
161 164
 <section2 topic='Introduction'>
162
-SAP Systems can create IDocs as receipts of transactions. These receipts can be used within other EDI systems, or within the SAP system. Of course transmission of IDocs can take place through XMPP as well.
165
+  <p>SAP Systems can create IDocs as receipts of transactions. These receipts can be used within other EDI systems, or within the SAP system. Of course transmission of IDocs can take place through XMPP as well.</p>
163 166
 </section2>
164 167
 
165 168
 <section2 topic='Protocol'>

+ 9
- 8
xep-0057.xml View File

@@ -13,6 +13,7 @@
13 13
     <status>Retracted</status>
14 14
     <type>Standards Track</type>
15 15
     <sig>Standards</sig>
16
+    <dependencies/>
16 17
     <supersedes/>
17 18
     <supersededby/>
18 19
     <shortname>None</shortname>
@@ -97,14 +98,14 @@
97 98
 	</ul>
98 99
       </section3>
99 100
       <section3 topic="Client JIDs">
100
-	  For all JIDs with category=client allowed following subtags:
101
-	<ul>
102
-	  <li>
103
-	    <strong>always-visible</strong>, <strong>always-invisible</strong>:
104
-	    The client should send custom presence to this JID to be always
105
-	    visible or invisible to it.
106
-	  </li>
107
-	</ul>
101
+        <p>For all JIDs with category=client allowed following subtags:</p>
102
+        <ul>
103
+          <li>
104
+            <strong>always-visible</strong>, <strong>always-invisible</strong>:
105
+            The client should send custom presence to this JID to be always
106
+            visible or invisible to it.
107
+          </li>
108
+        </ul>
108 109
       </section3>
109 110
       <section3 topic="Conference JIDs">
110 111
 	<p>

+ 14
- 5
xep-0058.xml View File

@@ -13,6 +13,10 @@
13 13
     <status>Deferred</status>
14 14
     <type>Standards Track</type>
15 15
     <sig>Standards</sig>
16
+    <dependencies/>
17
+    <supersedes/>
18
+    <supersededby/>
19
+    <shortname>N/A</shortname>
16 20
     <author>
17 21
       <firstname>Alexey</firstname>
18 22
       <surname>Shchepin</surname>
@@ -28,11 +32,16 @@
28 32
   </header>
29 33
 
30 34
   <section1 topic="Introduction">
31
-    This document defines an XMPP protocol extension for editing one text document by several people.
32
-    This can be useful when several people write different parts of one single document, or
33
-    one person edits the text and other people can see the changes.  The advantage of
34
-    using this protocol in compared to using a  version control systems is that all
35
-    changes are distributed between editors in real-time.
35
+    <p>
36
+      This document defines an XMPP protocol extension for editing one text
37
+      document by several people.
38
+      This can be useful when several people write different parts of one single
39
+      document, or one person edits the text and other people can see the
40
+      changes.
41
+      The advantage of using this protocol in compared to using a  version
42
+      control systems is that all changes are distributed between editors in
43
+      real-time.
44
+    </p>
36 45
   </section1>
37 46
 
38 47
   <section1 topic="Protocol description">

Loading…
Cancel
Save