moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Fix DTD check for 0017–0058

Browse Source
This commit is contained in:
Sam Whited 2017-01-01 14:08:18 -06:00
parent a4ea0907a0
commit 4f89d9467c
18 changed files with 202 additions and 154 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0017.xml
View File

@ -13,6 +13,10 @@
<status>Rejected</status> <status>Rejected</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Mike</firstname> <firstname>Mike</firstname>
<surname>Lin</surname> <surname>Lin</surname>

4
xep-0035.xml
View File

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

3
xep-0036.xml
View File

@ -13,8 +13,9 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/> <supersedes/>
<supersededby>XEP-0060</supersededby> <supersededby><spec>XEP-0060</spec></supersededby>
<shortname>None</shortname> <shortname>None</shortname>
&pgmillard; &pgmillard;
&stpeter; &stpeter;

4
xep-0037.xml
View File

@ -13,6 +13,10 @@
<status>Rejected</status> <status>Rejected</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>David</firstname> <firstname>David</firstname>
<surname>Sutton</surname> <surname>Sutton</surname>

73
xep-0038.xml
View File

@ -17,7 +17,6 @@
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>None</shortname> <shortname>None</shortname>
<schemaloc>Not yet assigned</schemaloc>
<author> <author>
<firstname>Adam</firstname> <firstname>Adam</firstname>
<surname>Theo</surname> <surname>Theo</surname>
@ -66,13 +65,13 @@
<section1 topic='Requirements'> <section1 topic='Requirements'>
<p>The following issues must be solved for in this specification.</p> <p>The following issues must be solved for in this specification.</p>
<ul> <ul>
<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> <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>
<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> <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>
<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> <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>
<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> <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>
<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> <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>
<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> <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>
<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> <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>
</ul> </ul>
<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> <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>
</section1> </section1>
@ -92,12 +91,12 @@
<section2 topic="Meta Elements"> <section2 topic="Meta Elements">
<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> <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>
<ul> <ul>
<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> <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>
<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> <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>
<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> <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>
<li><b>Author</b>: This is the full name of the author. Multiple authors are allowed.</li> <li><strong>Author</strong>: This is the full name of the author. Multiple authors are allowed.</li>
<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> <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>
<li><b>Home</b>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li> <li><strong>Home</strong>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li>
</ul> </ul>
</section2> </section2>
@ -196,29 +195,29 @@
<section2 topic='Core Icons'> <section2 topic='Core Icons'>
<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> <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>
<ul> <ul>
<li><b>:-)</b> and <b>:)</b> - A smiling face.</li> <li><strong>:-)</strong> and <strong>:)</strong> - A smiling face.</li>
<li><b>:-(</b> and <b>:(</b> - A frowing face.</li> <li><strong>:-(</strong> and <strong>:(</strong> - A frowing face.</li>
<li><b>;-)</b> and <b>;)</b> - A winking smiling face.</li> <li><strong>;-)</strong> and <strong>;)</strong> - A winking smiling face.</li>
<li><b>:'-(</b> and <b>:'(</b> - A crying face.</li> <li><strong>:'-(</strong> and <strong>:'(</strong> - A crying face.</li>
<li><b>>:-(</b> and <b>>:(</b> - An angry face.</li> <li><strong>>:-(</strong> and <strong>>:(</strong> - An angry face.</li>
<li><b>:yes:</b> - A thumbs-up or checkmark.</li> <li><strong>:yes:</strong> - A thumbs-up or checkmark.</li>
<li><b>:no:</b> - A thumbs-down or a crossmark.</li> <li><strong>:no:</strong> - A thumbs-down or a crossmark.</li>
<li><b>:wait:</b> - An open hand, palm outstretched.</li> <li><strong>:wait:</strong> - An open hand, palm outstretched.</li>
<li><b>@->--</b> and <b>:rose:</b> - A rose flower.</li> <li><strong>@->--</strong> and <strong>:rose:</strong> - A rose flower.</li>
<li><b>:telephone:</b> - A telephone.</li> <li><strong>:telephone:</strong> - A telephone.</li>
<li><b>:email:</b> - An electronic-looking envelope.</li> <li><strong>:email:</strong> - An electronic-looking envelope.</li>
<li><b>:jabber:</b> - Jabber's lightbulb logo.</li> <li><strong>:jabber:</strong> - Jabber's lightbulb logo.</li>
<li><b>:cake:</b> - A birthday cake.</li> <li><strong>:cake:</strong> - A birthday cake.</li>
<li><b>:kiss:</b> - A pair of puckered lips.</li> <li><strong>:kiss:</strong> - A pair of puckered lips.</li>
<li><b>:heart:</b> and <b>:love:</b> - A heart.</li> <li><strong>:heart:</strong> and <strong>:love:</strong> - A heart.</li>
<li><b>:brokenheart:</b> - A broken heart.</li> <li><strong>:brokenheart:</strong> - A broken heart.</li>
<li><b>:music:</b> - A musical note or instrument.</li> <li><strong>:music:</strong> - A musical note or instrument.</li>
<li><b>:beer:</b> - A beer mug.</li> <li><strong>:beer:</strong> - A beer mug.</li>
<li><b>:coffee:</b> - A cup of coffee.</li> <li><strong>:coffee:</strong> - A cup of coffee.</li>
<li><b>:money:</b> - A gold coin.</li> <li><strong>:money:</strong> - A gold coin.</li>
<li><b>:moon:</b> - A moon.</li> <li><strong>:moon:</strong> - A moon.</li>
<li><b>:sun:</b> - A sun.</li> <li><strong>:sun:</strong> - A sun.</li>
<li><b>:star:</b> - A star.</li> <li><strong>:star:</strong> - A star.</li>
</ul> </ul>
</section2> </section2>
</section1> </section1>

37
xep-0039.xml
View File

@ -13,6 +13,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies><spec>XEP-0053</spec></dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Paul</firstname> <firstname>Paul</firstname>
<surname>Curtis</surname> <surname>Curtis</surname>
@ -41,15 +45,18 @@
<version>0.6.0</version> <version>0.6.0</version>
<date>2002-11-05</date> <date>2002-11-05</date>
<initials>rkd</initials> <initials>rkd</initials>
<remark>Corrected David Sutton's JID and email. It has been pointed out <remark>
to me by amoungst others Rob Norris that things such as lists of JIDs Corrected David Sutton's JID and email.
and lists in general are really the province of disco and browse and It has been pointed out to me by amoungst others Rob Norris that things
that at least one of the suggested 'core' statistics doesn't such as lists of JIDs and lists in general are really the province of
make sense for all components so removed these from the document. This namespace disco and browse and that at least one of the suggested 'core'
was starting to become a generic data gathering namespace and we already statistics doesn't make sense for all components so removed these from
have one of those, so i've reworked yet again hopefully for the the document.
final time it should now be simpler to implement and more consistent in This namespace was starting to become a generic data gathering namespace
all cases.</remark> and we already have one of those, so I've reworked yet again hopefully
for the final time it should now be simpler to implement and more
consistent in all cases.
</remark>
</revision> </revision>
<revision> <revision>
<version>0.5.0</version> <version>0.5.0</version>
@ -157,7 +164,6 @@
<initials>rkd</initials> <initials>rkd</initials>
<remark>Initial version.</remark> <remark>Initial version.</remark>
</revision> </revision>
<dependencies>XEP-0053</dependencies>
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<p>As things currently stand it is not possible to obtain statistics <p>As things currently stand it is not possible to obtain statistics
@ -219,7 +225,6 @@
&lt;query xmlns='http://jabber.org/protocol/stats'/&gt; &lt;query xmlns='http://jabber.org/protocol/stats'/&gt;
&lt;/iq&gt; &lt;/iq&gt;
recv: &lt;iq type='result' from='component'&gt; recv: &lt;iq type='result' from='component'&gt;
&lt;query xmlns='http://jabber.org/protocol/stats'&gt; &lt;query xmlns='http://jabber.org/protocol/stats'&gt;
&lt;stat name='time/uptime'/&gt; &lt;stat name='time/uptime'/&gt;
@ -274,8 +279,6 @@
<tr><td>503</td><td>Service Unavailable</td><td>Statistic is <tr><td>503</td><td>Service Unavailable</td><td>Statistic is
temporarily unavailable</td></tr> temporarily unavailable</td></tr>
</table> </table>
<p>Because we wish to be able to collect groups of statistics <p>Because we wish to be able to collect groups of statistics
within a single returned packet errors must be handled in a two within a single returned packet errors must be handled in a two
tier way with authorization and core errors that would render tier way with authorization and core errors that would render
@ -310,7 +313,7 @@
<section2 topic='Name Registration'> <section2 topic='Name Registration'>
<p>All statistic names, returned data units types and other <p>All statistic names, returned data units types and other
pertinent statistic information will be assigned and registered with pertinent statistic information will be assigned and registered with
the Jabber Naming Authority in the category <em><strong>stat</strong></em>. the Jabber Naming Authority in the category <em><strong>stat</strong></em>
Unfortunately at this time such a body does not exist so we will Unfortunately at this time such a body does not exist so we will
have to rely on component and server authors diligently have to rely on component and server authors diligently
researching to ensure that their desired name is not already researching to ensure that their desired name is not already
@ -412,14 +415,14 @@
</section2> </section2>
</section1> </section1>
<section1 topic='Realworld Examples'> <section1 topic='Realworld Examples'>
TBD <p>TBD</p>
</section1> </section1>
<section1 topic='DTD'> <section1 topic='DTD'>
<section2 topic='DTD in English'> <section2 topic='DTD in English'>
TBD <p>TBD</p>
</section2> </section2>
<section2 topic='DTD'> <section2 topic='DTD'>
TBD <p>TBD</p>
</section2> </section2>
</section1> </section1>
</xep> </xep>

2
xep-0040.xml
View File

@ -15,7 +15,7 @@
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/> <dependencies/>
<supersedes/> <supersedes/>
<supersededby>XEP-0060</supersededby> <supersededby><spec>XEP-0060</spec></supersededby>
<shortname>None</shortname> <shortname>None</shortname>
<author> <author>
<firstname>Tim</firstname> <firstname>Tim</firstname>

20
xep-0041.xml
View File

@ -13,9 +13,13 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XMPP Core, XEP-0020, XEP-0030</dependencies> <dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0020</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby>XEP-0065</supersededby> <supersededby><spec>XEP-0065</spec></supersededby>
<shortname>rel</shortname> <shortname>rel</shortname>
<author> <author>
<firstname>Justin</firstname> <firstname>Justin</firstname>
@ -27,7 +31,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-09-30</date> <date>2003-09-30</date>
<initials>psa</initials> <initials>psa</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>0.8</version> <version>0.8</version>
@ -87,7 +91,10 @@
<p>A REL-compatible stream transport must have the following properties:</p> <p>A REL-compatible stream transport must have the following properties:</p>
<ul> <ul>
<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> <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>
<li>Has a the following link states: <li>Has link states from the following table.
</li>
<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>
</ul>
<table caption='Link states'> <table caption='Link states'>
<tr> <tr>
<th>Code</th> <th>Code</th>
@ -114,9 +121,6 @@
<td>Link failure after establishment (stream is closed, no further state)</td> <td>Link failure after establishment (stream is closed, no further state)</td>
</tr> </tr>
</table> </table>
</li>
<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>
</ul>
<p>The following stream transports that meet these guidelines are:</p> <p>The following stream transports that meet these guidelines are:</p>
<table caption='Supported streams'> <table caption='Supported streams'>
<tr> <tr>
@ -146,7 +150,7 @@
</iq> </iq>
]]></example> ]]></example>
The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol. <p>The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.</p>
<example caption='Response'><![CDATA[ <example caption='Response'><![CDATA[
<iq type="result" from="joe@blow.com/Home" id="sd_1"> <iq type="result" from="joe@blow.com/Home" id="sd_1">

8
xep-0042.xml
View File

@ -13,9 +13,13 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED)</dependencies> <dependencies>
<spec>XEP-0004 (OPTIONAL)</spec>
<spec>XEP-0011 (RECOMMENDED)</spec>
<spec>XEP-0029 (REQUIRED)</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby>XEP-0065</supersededby> <supersededby><spec>XEP-0065</spec></supersededby>
<shortname>JOBS</shortname> <shortname>JOBS</shortname>
<author> <author>
<firstname>Matthew</firstname> <firstname>Matthew</firstname>

7
xep-0043.xml
View File

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

6
xep-0044.xml
View File

@ -15,6 +15,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Robert</firstname> <firstname>Robert</firstname>
<surname>Norris</surname> <surname>Norris</surname>
@ -42,7 +46,6 @@
<section1 topic='Requirements and Protocol'> <section1 topic='Requirements and Protocol'>
<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> <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>
<example caption="A typical XML stream"><![CDATA[ <example caption="A typical XML stream"><![CDATA[
SEND: <stream:stream xmlns='jabber:client' SEND: <stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
@ -91,7 +94,6 @@ RECV: <iq type='result' from='jabber.org'>
</example> </example>
<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> <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>
<example caption="XML stream with arbitrary namespace prefixes (1)"><![CDATA[ <example caption="XML stream with arbitrary namespace prefixes (1)"><![CDATA[
SEND: <stream xmlns:app='jabber:client' SEND: <stream xmlns:app='jabber:client'
xmlns='http://etherx.jabber.org/streams' xmlns='http://etherx.jabber.org/streams'

2
xep-0046.xml
View File

@ -15,7 +15,7 @@
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/> <dependencies/>
<supersedes/> <supersedes/>
<supersededby>XEP-0065</supersededby> <supersededby><spec>XEP-0065</spec></supersededby>
<shortname>None</shortname> <shortname>None</shortname>
<author> <author>
<firstname>Justin</firstname> <firstname>Justin</firstname>

4
xep-0047.xml
View File

@ -18,10 +18,10 @@
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>ibb</shortname>
<schemaloc> <schemaloc>
<url>http://www.xmpp.org/schemas/ibb.xsd</url> <url>http://www.xmpp.org/schemas/ibb.xsd</url>
</schemaloc> </schemaloc>
<shortname>ibb</shortname>
&infiniti; &infiniti;
&stpeter; &stpeter;
<revision> <revision>
@ -216,7 +216,7 @@
<li>Because the sequence number has already been used, the recipient returns an &unexpected; error with a type of 'cancel'.</li> <li>Because the sequence number has already been used, the recipient returns an &unexpected; error with a type of 'cancel'.</li>
<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> <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>
</ol> </ol>
<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> <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>
<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> <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>
</section2> </section2>

4
xep-0051.xml
View File

@ -13,6 +13,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Klaus</firstname> <firstname>Klaus</firstname>
<surname>Wolf</surname> <surname>Wolf</surname>

13
xep-0052.xml
View File

@ -13,9 +13,18 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030</dependencies> <dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0020</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby>XEP-0095, XEP-0096</supersededby> <supersededby>
<spec>XEP-0095</spec>
<spec>XEP-0096</spec>
</supersededby>
<shortname>N/A</shortname> <shortname>N/A</shortname>
<author> <author>
<firstname>Thomas</firstname> <firstname>Thomas</firstname>

5
xep-0056.xml
View File

@ -14,6 +14,9 @@
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/> <dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Ulrich</firstname> <firstname>Ulrich</firstname>
<surname>Staudinger</surname> <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
<section1 topic='Transmitting SAP iDoc via XMPP'> <section1 topic='Transmitting SAP iDoc via XMPP'>
<section2 topic='Introduction'> <section2 topic='Introduction'>
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>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>
</section2> </section2>
<section2 topic='Protocol'> <section2 topic='Protocol'>

3
xep-0057.xml
View File

@ -13,6 +13,7 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>None</shortname> <shortname>None</shortname>
@ -97,7 +98,7 @@
</ul> </ul>
</section3> </section3>
<section3 topic="Client JIDs"> <section3 topic="Client JIDs">
For all JIDs with category=client allowed following subtags: <p>For all JIDs with category=client allowed following subtags:</p>
<ul> <ul>
<li> <li>
<strong>always-visible</strong>, <strong>always-invisible</strong>: <strong>always-visible</strong>, <strong>always-invisible</strong>:

19
xep-0058.xml
View File

@ -13,6 +13,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author> <author>
<firstname>Alexey</firstname> <firstname>Alexey</firstname>
<surname>Shchepin</surname> <surname>Shchepin</surname>
@ -28,11 +32,16 @@
</header> </header>
<section1 topic="Introduction"> <section1 topic="Introduction">
This document defines an XMPP protocol extension for editing one text document by several people. <p>
This can be useful when several people write different parts of one single document, or This document defines an XMPP protocol extension for editing one text
one person edits the text and other people can see the changes. The advantage of document by several people.
using this protocol in compared to using a version control systems is that all This can be useful when several people write different parts of one single
changes are distributed between editors in real-time. document, or one person edits the text and other people can see the
changes.
The advantage of using this protocol in compared to using a version
control systems is that all changes are distributed between editors in
real-time.
</p>
</section1> </section1>
<section1 topic="Protocol description"> <section1 topic="Protocol description">