moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

Turned some tables into definition lists.

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3567 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Tobias Markmann 2009-10-22 10:28:22 +00:00
parent 8a2c7b4aa8
commit 50c743adaf
3 changed files with 53 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
xep-0100.xml
View File

@ -100,32 +100,28 @@
<p>Note well that this document defines protocol usage with regard to client proxy gateways, i.e., gateways that "masquerade" as a client on a non-Jabber IM service. Gateways that perform direct protocol translation without proxying for an account on a non-Jabber service are not addressed in this document. Furthermore, this document does not define any interaction between a gateway and the non-Jabber service, only interactions between a Jabber client and the gateway. Although what happens on the other side of the gateway is highly dependent on the nature of the legacy service, gateways should at least provide a common interface on the Jabber side of the gateway so that Jabber clients can be written in a consistent fashion.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<table caption='Architectural Terms'>
<tr>
<th>Term</th>
<th>Definition</th>
</tr>
<tr>
<td>Gateway</td>
<td>A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this document, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service.</td>
</tr>
<tr>
<td>Jabber User</td>
<td>A human user who has registered an account with a Jabber server; a Jabber User who wants to use a Gateway must first have also registered an account with a Legacy Service.</td>
</tr>
<tr>
<td>Legacy Service</td>
<td>A non-XMPP instant messaging service.</td>
</tr>
<tr>
<td>Legacy User</td>
<td>A human user who has registered an account with a Legacy Service.</td>
</tr>
<tr>
<td>Server</td>
<td>An instant messaging server as defined in <cite>RFC 3921</cite>.</td>
</tr>
</table>
<dl>
<di>
<dt>Gateway</dt>
<dd>A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this document, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service.</dd>
</di>
<di>
<dt>Jabber User</dt>
<dd>A human user who has registered an account with a Jabber server; a Jabber User who wants to use a Gateway must first have also registered an account with a Legacy Service.</dd>
</di>
<di>
<dt>Legacy Service</dt>
<dd>A non-XMPP instant messaging service.</dd>
</di>
<di>
<dt>Legacy User</dt>
<dd>A human user who has registered an account with a Legacy Service.</dd>
</di>
<di>
<dt>Server</dt>
<dd>An instant messaging server as defined in <cite>RFC 3921</cite>.</dd>
</di>
</dl>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The requirements defined by this document are captured in two sets of use cases: one set from the perspective of the Jabber User, and a smaller set from the perspective of the Legacy User who wants to interact with the Jabber User.</p>

48
xep-0166.xml
View File

@ -594,32 +594,28 @@ Romeo Juliet
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='Glossary' anchor='terms-glossary'>
<table caption='Glossary'>
<tr>
<th>Term</th>
<th>Definition</th>
</tr>
<tr>
<td>Application Format</td>
<td>The data format of the content type being established, which formally declares one purpose of the session (e.g., "audio" or "video"). This is the 'what' of the session (i.e., the bits to be transferred), such as the acceptable codecs when establishing a voice conversation. In Jingle XML syntax the application format is the namespace of the &DESCRIPTION; element.</td>
</tr>
<tr>
<td>Component</td>
<td>A numbered stream of data that needs to be transmitted between the endpoints for a given content type in the context of a given session. It is up to the transport to negotiate the details of each component. Depending on the content type, multiple components might be needed (e.g., one to transmit an RTP stream and another to transmit RTCP timing information).</td>
</tr>
<tr>
<td>Content Type</td>
<td>A pair formed by the combination of one application format and one transport method.</td>
</tr>
<tr>
<td>Session</td>
<td>One or more content types negotiated between two entities. It is delimited in time by a session-initiate action and a session-terminate action. During the lifetime of a session, content types can be added or removed. A session consists of at least one content type at a time.</td>
</tr>
<tr>
<td>Transport Method</td>
<td>The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the <link url='#transports'>Transport Types</link> section of this document.</td>
</tr>
</table>
<dl>
<di>
<dt>Application Format</dt>
<dd>The data format of the content type being established, which formally declares one purpose of the session (e.g., "audio" or "video"). This is the 'what' of the session (i.e., the bits to be transferred), such as the acceptable codecs when establishing a voice conversation. In Jingle XML syntax the application format is the namespace of the &DESCRIPTION; element.</dd>
</di>
<di>
<dt>Component</dt>
<dd>A numbered stream of data that needs to be transmitted between the endpoints for a given content type in the context of a given session. It is up to the transport to negotiate the details of each component. Depending on the content type, multiple components might be needed (e.g., one to transmit an RTP stream and another to transmit RTCP timing information).</dd>
</di>
<di>
<dt>Content Type</dt>
<dd>A pair formed by the combination of one application format and one transport method.</dd>
</di>
<di>
<dt>Session</dt>
<dd>One or more content types negotiated between two entities. It is delimited in time by a session-initiate action and a session-terminate action. During the lifetime of a session, content types can be added or removed. A session consists of at least one content type at a time.</dd>
</di>
<di>
<dt>Transport Method</dt>
<dd>The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the <link url='#transports'>Transport Types</link> section of this document.</dd>
</di>
</dl>
</section2>
<section2 topic='Conventions' anchor='terms-conventions'>
<p>In diagrams, the following conventions are used:</p>

19
xep-0171.xml
View File

@ -104,16 +104,15 @@
<p>Direct translation can be realized by either client-side translation before sending or transparent components translating messages on the fly. Discovering XMPP entities capable of translation allows for clients to request translation from them based on their capabilities. The remote XMPP entity could be either an automated translation service or a human providing translation.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<table caption='Glossary'>
<tr><th>Term</th><th>Definition</th></tr>
<tr><td>Original Text</td><td>This is the message text that was originally created by the sender. This is the text that is translated.</td></tr>
<tr><td>Translated Text</td><td>This is the message text that has been translated by the language translation engines. This also called the destination text. For any given message there can be multiple destination text message bodies.</td></tr>
<tr><td>Pivot Language</td><td>Pivoting is the process of using one or more intermediate languages to translate from a given source language to a specific destination language. For example, if you needed to translate from English to Russian but only had translators that went from English to French and French to Russian then you could use French as a pivot language.</td></tr>
<tr><td>Pivot Text</td><td>This is the translated text of the original message in a pivot language. For any given destination language, there can be zero or more pivot text bodies. The ordering of pivoting is required to be specified for the destination language.</td></tr>
<tr><td>Language Translation Engine</td><td>Since not all language translation engines are the same quality it is important to some classes of users that they know what translation engine was used. It is equally important to also be able to select a specific translation engine for a given language pairing if more than one engine is available.</td></tr>
<tr><td>Language Translation Character Set</td><td>Some language translation engines can only translate text between languages if certain character sets (or code pages) are used.</td></tr>
<tr><td>Language Translation Dictionary</td><td> In order to enhance the accuracy of translation engines most support the concept of mission specific dictionaries.</td></tr>
</table>
<dl>
<di><dt>Original Text</dt><dd>This is the message text that was originally created by the sender. This is the text that is translated.</dd></di>
<di><dt>Translated Text</dt><dd>This is the message text that has been translated by the language translation engines. This also called the destination text. For any given message there can be multiple destination text message bodies.</dd></di>
<di><dt>Pivot Language</dt><dd>Pivoting is the process of using one or more intermediate languages to translate from a given source language to a specific destination language. For example, if you needed to translate from English to Russian but only had translators that went from English to French and French to Russian then you could use French as a pivot language.</dd></di>
<di><dt>Pivot Text</dt><dd>This is the translated text of the original message in a pivot language. For any given destination language, there can be zero or more pivot text bodies. The ordering of pivoting is required to be specified for the destination language.</dd></di>
<di><dt>Language Translation Engine</dt><dd>Since not all language translation engines are the same quality it is important to some classes of users that they know what translation engine was used. It is equally important to also be able to select a specific translation engine for a given language pairing if more than one engine is available.</dd></di>
<di><dt>Language Translation Character Set</dt><dd>Some language translation engines can only translate text between languages if certain character sets (or code pages) are used.</dd></di>
<di><dt>Language Translation Dictionary</dt><dd> In order to enhance the accuracy of translation engines most support the concept of mission specific dictionaries.</dd></di>
</dl>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein addresses the following requirements:</p>