moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0101–XEP-0185: Fix DTD

This commit is contained in:
Sam Whited 2017-01-01 19:56:24 -06:00
parent 5ae5dc1417
commit 424dd6c59b
23 changed files with 396 additions and 374 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0101.xml
View File

@ -13,11 +13,11 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>RFC 2616, RFC 2617, XEP-0030</dependencies>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
<spec>RFC 2616</spec> <spec>RFC 2616</spec>
<spec>RFC 2617</spec> <spec>RFC 2617</spec>
<spec>XEP-0030</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>

8
xep-0102.xml
View File

@ -361,8 +361,8 @@
</section1> </section1>
<section1 topic="Authenticated Key Agreement"> <section1 topic="Authenticated Key Agreement">
<section2 topic="Introduction"> <section2 topic="Introduction">
<p>The Diffie-Hellman key agreement algorithm <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref28269252">[10]</ulink> provides a mechanism to allow key establishment in a scalable and secure way. It allows two parties to agree on a shared value without requiring encryption. An Authenticated Key Agreement (AKE) is a secure protocol ensuring that in addition to securely sharing a secret, the two parties can be certain of each other&#8217;s identities, even when an active attacker exists.</p> <p>The Diffie-Hellman key agreement algorithm provides a mechanism to allow key establishment in a scalable and secure way. It allows two parties to agree on a shared value without requiring encryption. An Authenticated Key Agreement (AKE) is a secure protocol ensuring that in addition to securely sharing a secret, the two parties can be certain of each other&#8217;s identities, even when an active attacker exists.</p>
<p>This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27748789">[1]</ulink> and the OAKLEY key determination protocol <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27750056">[2]</ulink>. The purpose is to negotiate and provide authenticated key material for security association (SA) in a protected manner. The basic mechanism is the Diffie-Hellman Key Exchange. It provides the following addition to base key agreement:</p> <p>This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) and the OAKLEY key determination protocol. The purpose is to negotiate and provide authenticated key material for security association (SA) in a protected manner. The basic mechanism is the Diffie-Hellman Key Exchange. It provides the following addition to base key agreement:</p>
<ul> <ul>
<li>it uses weak address validation mechanism (cookies) to avoid denial of service attacks. <li>it uses weak address validation mechanism (cookies) to avoid denial of service attacks.
</li> </li>
@ -387,8 +387,8 @@
<p>The anti clogging tokens, or cookies, provide a weak form of source address identification for both parties. The cookies exchange can be completed before they perform the expensive computations later in the protocol. The cookies are used also for key naming.</p> <p>The anti clogging tokens, or cookies, provide a weak form of source address identification for both parties. The cookies exchange can be completed before they perform the expensive computations later in the protocol. The cookies are used also for key naming.</p>
<ul> <ul>
<li>The construction of the cookies is implementation dependent. It is recommended to make them the result of a one-way function applied to a secret value (changed periodically), and the local and remote addresses. In this way, the cookies remain stateless and expire periodically. Note that this would cause the KEYID's derived from the secret value to also expire, necessitating the removal of any state information associated with it. </li> <li>The construction of the cookies is implementation dependent. It is recommended to make them the result of a one-way function applied to a secret value (changed periodically), and the local and remote addresses. In this way, the cookies remain stateless and expire periodically. Note that this would cause the KEYID's derived from the secret value to also expire, necessitating the removal of any state information associated with it. </li>
<li>The encryption functions must be cryptographic transforms which guarantee privacy and integrity for the message data. They include any that satisfy this criteria and are defined for use with RFC2406 <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27753196">[3]</ulink>. </li> <li>The encryption functions must be cryptographic transforms which guarantee privacy and integrity for the message data. They include any that satisfy this criteria and are defined for use with &rfc2406;.</li>
<li>The one-way hash functions must be cryptographic transform which can be used as either keyed hash (pseudo-random) or non keyed transforms. They include any that are defined for use with RFC2406 <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27753196">[3]</ulink>. </li> <li>The one-way hash functions must be cryptographic transform which can be used as either keyed hash (pseudo-random) or non keyed transforms. They include any that are defined for use with <cite>RFC2406</cite>.</li>
<li>Where nonces are indicated they will be variable precision integers with an entropy value that match the strength attribute of the DH group used in the exchange.</li> <li>Where nonces are indicated they will be variable precision integers with an entropy value that match the strength attribute of the DH group used in the exchange.</li>
</ul> </ul>
</section2> </section2>

4
xep-0103.xml
View File

@ -132,8 +132,8 @@
<li>Once retrieval is complete, the Receiver responds to Sender (EUC).</li> <li>Once retrieval is complete, the Receiver responds to Sender (EUC).</li>
</ol> </ol>
<ul> <ul>
<li><b>E1:</b> The given URL is not supported/understood</li> <li><strong>E1:</strong> The given URL is not supported/understood</li>
<li><b>E2:</b> Failure to connect to the given URL</li> <li><strong>E2:</strong> Failure to connect to the given URL</li>
</ul> </ul>
<p>The sender starts with an SI request, using the semantics from XEP-0095:</p> <p>The sender starts with an SI request, using the semantics from XEP-0095:</p>
<example caption='Requesting SI transfer'><![CDATA[ <example caption='Requesting SI transfer'><![CDATA[

5
xep-0105.xml
View File

@ -13,7 +13,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XEP-0095, XEP-0096</dependencies> <dependencies>
<spec>XEP-0095</spec>
<spec>XEP-0096</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>si-treetransfer</shortname> <shortname>si-treetransfer</shortname>

6
xep-0106.xml
View File

@ -204,9 +204,9 @@
</section2> </section2>
<section2 topic='Exceptions' anchor='bizrules-exceptions'> <section2 topic='Exceptions' anchor='bizrules-exceptions'>
<p>In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored (with the exception of the escaping character '\' itself in the rare case when the source address includes the sequence '\5c').</p> <p>In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored (with the exception of the escaping character '\' itself in the rare case when the source address includes the sequence '\5c').</p>
<example caption='Partial escape sequence'><strong>\2plus\2is\4</strong> is not modified by escaping or unescaping transformations.</example> <example caption='Partial escape sequence'>"\2plus\2is\4" is not modified by escaping or unescaping transformations.</example>
<example caption='Invalid escape sequence 1'><strong>foo\bar</strong> is not modified (to <strong>foo&#186;r</strong>) by escaping or unescaping transformations.</example> <example caption='Invalid escape sequence 1'>"foo\bar" is not modified (to "foo&#186;r") by escaping or unescaping transformations.</example>
<example caption='Invalid escape sequence 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) by escaping or unescaping transformations.</example> <example caption='Invalid escape sequence 2'>"foob\41r" is not modified (to "foobAr") by escaping or unescaping transformations.</example>
<p>However, \5c would be escaped if found in the source address (e.g., a source address of "c:\5commas@example.com" would be escaped to "c\3a\5c5commas@example.com") and unescaped if contained in the JID-on-the-wire (e.g., a JID-on-the-wire of "c\3a\5c5commas@example.com" would be unescaped back to "c:\5commas@example.com").</p> <p>However, \5c would be escaped if found in the source address (e.g., a source address of "c:\5commas@example.com" would be escaped to "c\3a\5c5commas@example.com") and unescaped if contained in the JID-on-the-wire (e.g., a JID-on-the-wire of "c\3a\5c5commas@example.com" would be unescaped back to "c:\5commas@example.com").</p>
</section2> </section2>
<section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'> <section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>

5
xep-0109.xml
View File

@ -13,7 +13,10 @@
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XEP-0060, XEP-0163</dependencies> <dependencies>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>ooo</shortname> <shortname>ooo</shortname>

2
xep-0119.xml
View File

@ -156,7 +156,7 @@ Service | Manager
<td>REQUIRED *</td> <td>REQUIRED *</td>
</tr> </tr>
</table> </table>
<p><em>* Note: The User Avatar specification (<cite>XEP-0084</cite>) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</em></p> <p>* <em>Note:</em> The User Avatar specification (<cite>XEP-0084</cite>) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</p>
</section1> </section1>
<section1 topic='Node Discovery' anchor='discovery'> <section1 topic='Node Discovery' anchor='discovery'>
<p>Discovery of extended presence pubsub nodes is expedited through the use of <cite>Personal Eventing via Pubsub</cite> (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:</p> <p>Discovery of extended presence pubsub nodes is expedited through the use of <cite>Personal Eventing via Pubsub</cite> (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:</p>

2
xep-0120.xml
View File

@ -16,7 +16,7 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XMPP Core</dependencies> <dependencies><spec>XMPP Core</spec></dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>infobits</shortname> <shortname>infobits</shortname>

2
xep-0121.xml
View File

@ -16,7 +16,7 @@
<status>Retracted</status> <status>Retracted</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XEP-0120</dependencies> <dependencies><spec>XEP-0120</spec></dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>

7
xep-0123.xml
View File

@ -16,7 +16,12 @@
<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-0030, XEP-0120</dependencies> <dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0030</spec>
<spec>XEP-0120</spec>
</dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>

2
xep-0125.xml
View File

@ -16,7 +16,7 @@
<status>Retracted</status> <status>Retracted</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies>XEP-0120</dependencies> <dependencies><spec>XEP-0120</spec></dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>

2
xep-0133.xml
View File

@ -132,7 +132,7 @@
<li>Shut Down Service</li> <li>Shut Down Service</li>
</ol> </ol>
<p>Naturally, not all of these use cases apply to all service types (e.g., adding a user may not apply to a multi-user chat service). An implementation or deployment MAY support any subset of the use cases defined herein. In addition, although this document aims to define common use cases, an implementation or deployment MAY support additional commands not defined herein, which may or may not be publicly registered.</p> <p>Naturally, not all of these use cases apply to all service types (e.g., adding a user may not apply to a multi-user chat service). An implementation or deployment MAY support any subset of the use cases defined herein. In addition, although this document aims to define common use cases, an implementation or deployment MAY support additional commands not defined herein, which may or may not be publicly registered.</p>
<p><em>Note: The text that follows assumes that implementors have read and understood <cite>XEP-0050: Ad-Hoc Commands</cite> and <cite>XEP-0004: Data Forms</cite>.</em></p> <p><em>Note:</em> The text that follows assumes that implementors have read and understood <cite>XEP-0050: Ad-Hoc Commands</cite> and <cite>XEP-0004: Data Forms</cite>.</p>
<section2 topic='Add User' anchor='add-user'> <section2 topic='Add User' anchor='add-user'>
<p>A user is defined as any entity that has a persistent relationship with a service (most commonly through the creation a registered account with the service) and whose account is in some sense hosted by the service. Adding a user MUST result in the creation of an account, along with any implementation-specific data for such an account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-user".</p> <p>A user is defined as any entity that has a persistent relationship with a service (most commonly through the creation a registered account with the service) and whose account is in some sense hosted by the service. Adding a user MUST result in the creation of an account, along with any implementation-specific data for such an account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-user".</p>
<p>A sample protocol flow for this use case is shown below.</p> <p>A sample protocol flow for this use case is shown below.</p>

2
xep-0137.xml
View File

@ -237,7 +237,7 @@
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Notes' achor='impl-notes'> <section1 topic='Implementation Notes' anchor='impl-notes'>
<section2 topic='Publish ID versus SI ID'> <section2 topic='Publish ID versus SI ID'>
<p>When publishing a stream via the &lt;sipub/&gt; element, the identifier SHOULD NOT be used as-is for the &lt;si/&gt; element, since a single publication will likely result in multiple &lt;si/&gt; requests, possibly from the same receiver.</p> <p>When publishing a stream via the &lt;sipub/&gt; element, the identifier SHOULD NOT be used as-is for the &lt;si/&gt; element, since a single publication will likely result in multiple &lt;si/&gt; requests, possibly from the same receiver.</p>
</section2> </section2>

242
xep-0146.xml
View File

@ -226,25 +226,29 @@
<section2 topic='Forward Unread Messages Residing at a Remote Client' anchor='forward'> <section2 topic='Forward Unread Messages Residing at a Remote Client' anchor='forward'>
<p>A user might want to forward all the unread messages residing at <p>
the remote client to the local client (e.g. when the remote client was A user might want to forward all the unread messages residing at the
accidentally left on-line, and has received messages in the meantime).</p> remote client to the local client (e.g. when the remote client was
accidentally left on-line, and has received messages in the meantime).
</p>
<p>
For example, suppose Romeo sends a message to Juliet, thinking she is For example, suppose Romeo sends a message to Juliet, thinking she is
still on her balcony. The balcony client receives the message: still on her balcony.
<example caption='Remote Client Receives Message'><![CDATA[ The balcony client receives the message:
<message from='romeo@example.com/orchard' </p>
<example caption='Remote Client Receives Message'><![CDATA[
<message from='romeo@example.com/orchard'
to='juliet@example.com/balcony'> to='juliet@example.com/balcony'>
<subject>Just saying hi</subject> <subject>Just saying hi</subject>
<body>Hello Juliet!</body> <body>Hello Juliet!</body>
</message> </message>]]></example>
]]></example> <p>
However, Juliet is in her chamber, so she doesn't know about the message However, Juliet is in her chamber, so she doesn't know about the message
(yet). Realizing she left her balcony client unattended, she sends a (yet).
request to the remote client to forward all unread messages. Realizing she left her balcony client unattended, she sends a request to
the remote client to forward all unread messages.
<example caption='Local Client Requests to Forward Unread Messages Currently Residing at the Remote Client'><![CDATA[ </p>
<example caption='Local Client Requests to Forward Unread Messages Currently Residing at the Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
type='set' type='set'
@ -254,122 +258,120 @@
action='execute' action='execute'
node='http://jabber.org/protocol/rc#forward' node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z'/> sessionid='forward:20040727T0337Z'/>
</iq> </iq>]]></example>
]]></example> <p>
The client forwards all unread messages to the local client, adding The client forwards all unread messages to the local client, adding
information about the origin of the message (using the 'ofrom' information about the origin of the message (using the 'ofrom' &xep0033;
&xep0033; address, and the &xep0203; timestamp of the original message). address, and the &xep0203; timestamp of the original message).
The chamber client receives both these messages and a The chamber client receives both these messages and a confirmation that
confirmation that the command was completed. the command was completed.
<example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[ </p>
<example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
<message from='juliet@example.com/balcony' <message from='juliet@example.com/balcony'
to='juliet@example.com/chamber'> to='juliet@example.com/chamber'>
<subject>Just saying hi</subject> <subject>Just saying hi</subject>
<body>Hello Juliet!</body> <body>Hello Juliet!</body>
<addresses xmlns='http://jabber.org/protocol/address'> <addresses xmlns='http://jabber.org/protocol/address'>
<address type='ofrom' jid='romeo@example.com/orchard'/> <address type='ofrom' jid='romeo@example.com/orchard'/>
</addresses> </addresses>
<delay xmlns='urn:xmpp:delay' <delay xmlns='urn:xmpp:delay'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
stamp='2002-09-10T23:41:07Z'/> stamp='2002-09-10T23:41:07Z'/>
</message> </message>]]></example>
]]></example> <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='forward-1' id='forward-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#forward' node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z' sessionid='forward:20040727T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>]]></example>
]]></example> <p>
A client MAY provide a more fine-grained implementation, e.g. by
A client MAY provide a more fine-grained implementation, e.g. by presenting the requester an extra form to select which messages have to
presenting the requester an extra form to select which messages be forwarded.
have to be forwarded. </p>
</section2> </section2>
<section2 topic='Change Run-Time Options'> <section2 topic='Change Run-Time Options'>
<p>It might be desirable to remotely set some run-time options of <p>
a client. For example, when neighbours complain about the sounds your It might be desirable to remotely set some run-time options of a client.
client makes while you're at another location, you could turn the For example, when neighbours complain about the sounds your client makes
sounds off at the remote client. while you're at another location, you could turn the sounds off at the
</p> remote client.
<example caption='Local Client Requests to Change Options of a Remote Client'><![CDATA[ </p>
<example caption='Local Client Requests to Change Options of a Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
type='set' type='set'
id='set-options-1' id='set-options-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='http://jabber.org/protocol/rc#set-options'/> node='http://jabber.org/protocol/rc#set-options'/>
</iq> </iq>]]></example>
]]></example> <p>
<p>Unless an error occurs (see the Unless an error occurs (see the <link url='#errors'>Error
<link url='#errors'>Error Handling</link> section below), the service Handling</link> section below), the service SHOULD return the
SHOULD return the appropriate form.</p> appropriate form.
</p>
<example caption='Remote Client Replies with a Form to Set its Options'><![CDATA[ <example caption='Remote Client Replies with a Form to Set its Options'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='set-options-1' id='set-options-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-options' node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z' sessionid='set-options:20040727T0337Z'
status='executing'> status='executing'>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Set Options</title> <title>Set Options</title>
<instructions>Set the desired options</instructions> <instructions>Set the desired options</instructions>
<field type='hidden' var='FORM_TYPE'> <field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value> <value>http://jabber.org/protocol/rc</value>
</field> </field>
<field label='Play sounds' <field label='Play sounds'
type='boolean' type='boolean'
var='sounds'> var='sounds'>
<value>1</value> <value>1</value>
</field> </field>
<field label='Automatically Go Offline when Idle' <field label='Automatically Go Offline when Idle'
type='boolean' type='boolean'
var='auto-offline'> var='auto-offline'>
<value>0</value> <value>0</value>
</field> </field>
<field label='Automatically Open New Messages' <field label='Automatically Open New Messages'
type='boolean' type='boolean'
var='auto-msg'> var='auto-msg'>
<value>0</value> <value>0</value>
</field> </field>
<field label='Automatically Accept File Transfers' <field label='Automatically Accept File Transfers'
type='boolean' type='boolean'
var='auto-files'> var='auto-files'>
<value>0</value> <value>0</value>
</field> </field>
<field label='Automatically Authorize Contacts' <field label='Automatically Authorize Contacts'
type='boolean' type='boolean'
var='auto-auth'> var='auto-auth'>
<value>0</value> <value>0</value>
</field> </field>
</x> </x>
</command> </command>
</iq> </iq>]]></example>
]]></example> <example caption='Local Client Submits Set Options Form to Remote Client'><![CDATA[
<example caption='Local Client Submits Set Options Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
type='set' type='set'
id='set-options-2' id='set-options-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-options' node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z'> sessionid='set-options:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'> <field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value> <value>http://jabber.org/protocol/rc</value>
@ -392,30 +394,30 @@
</x> </x>
</command> </command>
</iq> </iq>
]]></example> ]]></example>
<p>The remote client sets the values of the options to their requested <p>
value. If a variable is omitted, the client SHOULD NOT change the value of the The remote client sets the values of the options to their requested
corresponding option.</p> value.
If a variable is omitted, the client SHOULD NOT change the value of the
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[ corresponding option.
<iq from='juliet@example.com/balcony' </p>
to='juliet@example.com/chamber' <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
type='result' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='result'
id='set-options-2' id='set-options-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-options' node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z' sessionid='set-options:20040727T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>]]></example>
]]></example> <p>
<p>Notification of completion MAY include the processed data in a data Notification of completion MAY include the processed data in a data form
form of type 'result'.</p> of type 'result'.
</p>
</section2> </section2>
<!-- ************************************************************************ -->
<section2 topic='Accept Pending File Transfer Requests'> <section2 topic='Accept Pending File Transfer Requests'>
<example caption='Local Client Requests to Accept Pending File Transfer Requests on the Remote Client'><![CDATA[ <example caption='Local Client Requests to Accept Pending File Transfer Requests on the Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
@ -426,16 +428,16 @@
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='http://jabber.org/protocol/rc#accept-files'/> node='http://jabber.org/protocol/rc#accept-files'/>
</iq> </iq>]]></example>
]]></example> <p>
<p>Unless an error occurs (see the Unless an error occurs (see the <link url='#errors'>Error Handling</link>
<link url='#errors'>Error Handling</link> section below), the service section below), the service SHOULD return the appropriate form.
SHOULD return the appropriate form.</p> </p>
<example caption='Remote Client Replies with a Form Containing Pending File Transfers'><![CDATA[ <example caption='Remote Client Replies with a Form Containing Pending File Transfers'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='accept-files-1' id='accept-files-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -464,8 +466,7 @@
</field> </field>
</x> </x>
</command> </command>
</iq> </iq>]]></example>
]]></example>
<example caption='Local Client Submits Form to Remote Client'><![CDATA[ <example caption='Local Client Submits Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber' <iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
@ -484,11 +485,11 @@
</field> </field>
</x> </x>
</command> </command>
</iq> </iq>]]></example>
]]></example> <p>
The remote client accepts the selected file transfers, and informs the
The remote client accepts the selected file transfers, and informs local client of completion.
the local client of completion. </p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[ <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
@ -499,8 +500,7 @@
node='http://jabber.org/protocol/rc#accept-files' node='http://jabber.org/protocol/rc#accept-files'
sessionid='accept-files:20040727T0337Z' sessionid='accept-files:20040727T0337Z'
status='completed'/> status='completed'/>
</iq> </iq>]]></example>
]]></example>
</section2> </section2>

354
xep-0151.xml
View File

@ -105,22 +105,20 @@
<p>Meeting on virtual locations is very similar to meeting peers in a public chat room. But web pages can be regarded as 2 dimensional. They very often cover the entire screen. They use graphics elements for their content. Plainly speaking: representing users as figures or other images fits well to web pages. Once they are shown as individual figures, a line based chat and a chat window are not required any more (though a chat window can still be used). The figures can move around and talk in chat bubble style. Chat bubbles in turn enable incremental chat.</p> <p>Meeting on virtual locations is very similar to meeting peers in a public chat room. But web pages can be regarded as 2 dimensional. They very often cover the entire screen. They use graphics elements for their content. Plainly speaking: representing users as figures or other images fits well to web pages. Once they are shown as individual figures, a line based chat and a chat window are not required any more (though a chat window can still be used). The figures can move around and talk in chat bubble style. Chat bubbles in turn enable incremental chat.</p>
<p>This document describes protocol elements for <p>This document describes protocol elements for:</p>
<ul> <ul>
<li>the visualization of users on web pages (animated avatars) and</li> <li>the visualization of users on web pages (animated avatars) and</li>
<li>communication beyond line based group chat (incremental or instant bubble chat)</li> <li>communication beyond line based group chat (incremental or instant bubble chat)</li>
</ul> </ul>
</p>
<p>While users are browsing the web, they enter and leave many rooms. They meet many people and some of them multiple times. Minimum overall traffic and minimum traffic on the user connection are primary design goals. The user connection is limited by typical karma settings of jabber servers. Logging in to virtual locations (rooms) must be quick in terms of round trips and cheap in terms of traffic. Once logged in to a room, the traffic on the user connection should be independent of the number of peers already present. </p> <p>While users are browsing the web, they enter and leave many rooms. They meet many people and some of them multiple times. Minimum overall traffic and minimum traffic on the user connection are primary design goals. The user connection is limited by typical karma settings of jabber servers. Logging in to virtual locations (rooms) must be quick in terms of round trips and cheap in terms of traffic. Once logged in to a room, the traffic on the user connection should be independent of the number of peers already present. </p>
<p>The extensions have been designed to be: <p>The extensions have been designed to be:</p>
<ul> <ul>
<li>compatible to the existing Jabber infrastructure and protocols,</li> <li>compatible to the existing Jabber infrastructure and protocols,</li>
<li>lightweight with respect to the number of new elements,</li> <li>lightweight with respect to the number of new elements,</li>
<li>lightweight with respect to the traffic generated.</li> <li>lightweight with respect to the traffic generated.</li>
</ul> </ul>
</p>
<p>The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.</p> <p>The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.</p>
@ -146,33 +144,31 @@
<p>The mapping process should try to protect the privacy of the user. After all, virtual presence is a violation of privacy in general, because people know where other people are (virtually). This is critical, if compared to the totally un-observed Web without virtual presence. In the real world people are used to being seen in physical locations, but only by others who are physically present in the same location. The mapping process should emulate this restriction. The general idea is to include a one way function (message digest) during the mapping process to prohibit the discovery of &apos;interesting&apos; chat room names. In other words: observers must do the forward mapping and enter a room to see who is there or discover random room names without being able to re-create the source URL. So, they may be able to find people in random rooms, but do not know the virtual location.</p> <p>The mapping process should try to protect the privacy of the user. After all, virtual presence is a violation of privacy in general, because people know where other people are (virtually). This is critical, if compared to the totally un-observed Web without virtual presence. In the real world people are used to being seen in physical locations, but only by others who are physically present in the same location. The mapping process should emulate this restriction. The general idea is to include a one way function (message digest) during the mapping process to prohibit the discovery of &apos;interesting&apos; chat room names. In other words: observers must do the forward mapping and enter a room to see who is there or discover random room names without being able to re-create the source URL. So, they may be able to find people in random rooms, but do not know the virtual location.</p>
<p>This mapping process is designed to <p>This mapping process is designed to:</p>
<ul> <ul>
<li>make the virtual presence service a distributed network of jabber servers, i.e. conference components,</li> <li>make the virtual presence service a distributed network of jabber servers, i.e. conference components,</li>
<li>allow for flexible mapping from URLs to JIDs, taking into account that <li>allow for flexible mapping from URLs to JIDs, taking into account that
<ul> <ul>
<li>most URLs are path based,</li> <li>most URLs are path based,</li>
<li>URLs contain queries,</li> <li>URLs contain queries,</li>
<li>sometimes only the query part defines the virtual location,</li> <li>sometimes only the query part defines the virtual location,</li>
<li>groups of URLs map to a single JID,</li> <li>groups of URLs map to a single JID,</li>
<li>a single virtual location may comprise multiple web servers,</li> <li>a single virtual location may comprise multiple web servers,</li>
<li>groups of URLs may only cover a sub-folder of path based URLs,</li> <li>groups of URLs may only cover a sub-folder of path based URLs,</li>
<li>not all URLs are known at config time,</li> <li>not all URLs are known at config time,</li>
</ul> </ul>
</li> </li>
<li>allow operators of websites to control the mapping for the URL-space they control,</li> <li>allow operators of websites to control the mapping for the URL-space they control,</li>
<li>let websites opt out of virtual presence,</li> <li>let websites opt out of virtual presence,</li>
<li>allow for hierarchical configuration for file system path based URLs,</li> <li>allow for hierarchical configuration for file system path based URLs,</li>
<li>support delegation,</li> <li>support delegation,</li>
<li>allow for virtual presence without the cooperation of the website,</li> <li>allow for virtual presence without the cooperation of the website,</li>
<li>allow for distribution of the load of the default configuration server,</li> <li>allow for distribution of the load of the default configuration server,</li>
<li>support commercial virtual presence servers and rented rooms,</li> <li>support commercial virtual presence servers and rented rooms,</li>
<li>be extensible to other protocols as virtual presence transport,</li> <li>be extensible to other protocols as virtual presence transport,</li>
<li>be easily implemented by website operators,</li> <li>be easily implemented by website operators,</li>
<li>at least limit the privacy issues associated with virtual presence.</li> <li>at least limit the privacy issues associated with virtual presence.</li>
</ul> </ul>
</p>
</section2> </section2>
</section1> </section1>
@ -207,11 +203,8 @@
</section2> </section2>
<section2 topic='Getting more information'> <section2 topic='Getting more information'>
<p>For more information about &apos;YoungHero&apos; beyond the nickname Juliet needs a JID (see below for anonymous variants of the avatar image). Non-anonymous rooms will supply the JIDs automatically. But we suggest that rooms, which make up the virtual presence network are configured to be anonymous so that users can choose if they want to disclose the JID. We propose an extension to the &PRESENCE; stanza for users to supply their JID automatically to peers in anonymous rooms with minimum traffic even for many participants. </p> <p>For more information about &apos;YoungHero&apos; beyond the nickname Juliet needs a JID (see below for anonymous variants of the avatar image). Non-anonymous rooms will supply the JIDs automatically. But we suggest that rooms, which make up the virtual presence network are configured to be anonymous so that users can choose if they want to disclose the JID. We propose an extension to the &PRESENCE; stanza for users to supply their JID automatically to peers in anonymous rooms with minimum traffic even for many participants. </p>
<p>Note: even though Romeo sends a JID, the systems is still anonymous. Romeo could send any JID. He may send a (fake) JID that is just the base address of his storage, but not his communication address. In anonymous rooms Juliet will use any JID Romeo provides. If the room is not anonymous, then Romeo&apos;s client may use Juliet&apos;s actual JID. </p> <p>Note: even though Romeo sends a JID, the systems is still anonymous. Romeo could send any JID. He may send a (fake) JID that is just the base address of his storage, but not his communication address. In anonymous rooms Juliet will use any JID Romeo provides. If the room is not anonymous, then Romeo&apos;s client may use Juliet&apos;s actual JID. </p>
<p>Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.</p> <p>Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.</p>
<example caption='Disclosing the JID'><![CDATA[ <example caption='Disclosing the JID'><![CDATA[
@ -224,13 +217,12 @@
<p>This tells the conference component to send the JID to all participants automatically. Romeo will receive the &PRESENCE; stanza including the JID element. Romeo may now fetch Juliet&apos;s avatar or add Juliet to a buddy list. </p> <p>This tells the conference component to send the JID to all participants automatically. Romeo will receive the &PRESENCE; stanza including the JID element. Romeo may now fetch Juliet&apos;s avatar or add Juliet to a buddy list. </p>
<p>Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons: <p>Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons:</p>
<ol> <ol>
<li>to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,</li> <li>to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,</li>
<li>to allow for caching of extended information.</li> <li>to allow for caching of extended information.</li>
</ol> </ol>
Caching requires a persistent and unique id per user. While a message digest of the JID would be sufficient for caching extended information, it is not sufficient for retrieving extended information. <p>Caching requires a persistent and unique id per user. While a message digest of the JID would be sufficient for caching extended information, it is not sufficient for retrieving extended information.</p>
</p>
</section2> </section2>
@ -464,17 +456,14 @@ as part of:
<p>The video format is the common, widely used webcam format introduced by Netscape (JPEG server-pushed).</p> <p>The video format is the common, widely used webcam format introduced by Netscape (JPEG server-pushed).</p>
<p>In the real world there are many Romeos and Juliets even on the same page at the same time. Some of them with a webcam. Depending on the default settings of VP clients all users (say 8) will automatically request the videos of the subset of users equipped with a webcam (say 3). This automatically creates many video streams, 3 streams on the dialup line of all users and 7 streams on the line of webcam users. We therefore suggest the following optimizations and limitations: <p>In the real world there are many Romeos and Juliets even on the same page at the same time. Some of them with a webcam. Depending on the default settings of VP clients all users (say 8) will automatically request the videos of the subset of users equipped with a webcam (say 3). This automatically creates many video streams, 3 streams on the dialup line of all users and 7 streams on the line of webcam users. We therefore suggest the following optimizations and limitations:</p>
<ul> <ul>
<li>video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,</li> <li>video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,</li>
<li>the frame rate should not exceed 3 frames per second for simple web browsing (special applications, especially assymmetric ones, like virtual class rooms, presentations may differ),</li> <li>the frame rate should not exceed 3 frames per second for simple web browsing (special applications, especially assymmetric ones, like virtual class rooms, presentations may differ),</li>
<li>for small sizes, quantization tables and Huffman tables make much more data than the encoded image. Therefore, the DQT and DHT markers should be stripped from JPEG frames except for the first frame of a stream. Only the JPEG baseline algorithm is supported with static Huffman tables,</li> <li>for small sizes, quantization tables and Huffman tables make much more data than the encoded image. Therefore, the DQT and DHT markers should be stripped from JPEG frames except for the first frame of a stream. Only the JPEG baseline algorithm is supported with static Huffman tables,</li>
<li>VP clients which support such a optimized JPEG server-push format should add a &apos;Accept: image/djpeg&apos; header to the HTTP request. (djpeg for differential JPEG)</li> <li>VP clients which support such a optimized JPEG server-push format should add a &apos;Accept: image/djpeg&apos; header to the HTTP request. (djpeg for differential JPEG)</li>
</ul> </ul>
<p>The purpose of these limitations is to allow for webcams which send optimized streams of small images (reducing the data volume by a factor of 3) while supporting usual webcams.</p>
The purpose of these limitations is to allow for webcams which send optimized streams of small images (reducing the data volume by a factor of 3) while supporting usual webcams.
</p>
</section2> </section2>
</section1> </section1>
@ -626,29 +615,29 @@ http://www.shakespeare.com/_vpi.xml]]>
<p>This section is intended as a guideline for the implementation of the mapping process.</p> <p>This section is intended as a guideline for the implementation of the mapping process.</p>
<p>The mapping has 2 phases: <p>The mapping has 2 phases:</p>
<ol> <ol>
<li>finding the rule</li> <li>finding the rule</li>
<li>applying the rule</li> <li>applying the rule</li>
</ol> </ol>
</p>
<section3 topic='Find the Rule'> <section3 topic='Find the Rule'>
<p> <p>We get a URL from the web browser, say:</p>
We get a URL from the web browser, say <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code> <p>We try to fetch the configuration file from</p>
We try to fetch the configuration file from <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/_vpi.xml]]></code>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/_vpi.xml]]></code> <p>The request fails (the failure is noted in the cache), and we try</p>
The request fails (the failure is noted in the cache), and we try <code><![CDATA[http://www.shakespeare.com/market/_vpi.xml]]></code>
<code><![CDATA[http://www.shakespeare.com/market/_vpi.xml]]></code> <p>The request fails again (the failure is noted in the cache). We try</p>
The request fails again (the failure is noted in the cache). We try <code><![CDATA[http://www.shakespeare.com/_vpi.xml]]></code>
<code><![CDATA[http://www.shakespeare.com/_vpi.xml]]></code> <p>
We do not find it (the failure is noted in the cache), and we revert to the We do not find it (the failure is noted in the cache), and we revert to
global file (which one depends on the client configuration) the global file (which one depends on the client configuration)
<code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml]]></code> </p>
The request returns (and the data is stored in the cache): <code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml]]></code>
<code><![CDATA[ <p>The request returns (and the data is stored in the cache):</p>
<code><![CDATA[
<?xml version='1.0' ?> <?xml version='1.0' ?>
<vpi xmlns='http://schema.bluehands.de/virtual-presence-info'> <vpi xmlns='http://schema.bluehands.de/virtual-presence-info'>
@ -670,20 +659,25 @@ http://www.shakespeare.com/_vpi.xml]]>
<digest/> <digest/>
</location> </location>
</vpi>]]></code> </vpi>]]></code>
<p>We try to find a &lt;location/&gt; that matches our URL. We find:</p>
We try to find a &lt;location/&gt; that matches our URL. We find: <code><![CDATA[
<code><![CDATA[
<location match='^http://.*\.com/.*'> <location match='^http://.*\.com/.*'>
<delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate> <delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
</location>]]></code> </location>]]></code>
This means that all .com domains are forwarded to a separate VPI file. <p>
This means that all .com domains are forwarded to a separate VPI file.
We fetch: We fetch:
<code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml]]></code> </p>
<code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml]]></code>
We store the result in the cache and search for a matching &lt;location/&gt; <p>
again. We find the default section (rest of the file omitted, the match-attribute is more general than the one of the previous &lt;delegate/&gt;, because here we are already in the .com domain): We store the result in the cache and search for a matching
<code><![CDATA[ &lt;location/&gt; again.
We find the default section (rest of the file omitted, the match-attribute
is more general than the one of the previous &lt;delegate/&gt;, because
here we are already in the .com domain):
</p>
<code><![CDATA[
... ...
<location match='^http://([^/]+)($|/.*$)'> <location match='^http://([^/]+)($|/.*$)'>
<service>xmpp:location.virtual-presence.org</service> <service>xmpp:location.virtual-presence.org</service>
@ -693,90 +687,88 @@ http://www.shakespeare.com/_vpi.xml]]>
</location> </location>
...]]></code> ...]]></code>
The &lt;location/&gt; matches, so we get a virtual presence <p>
service address and a set of rules. The &lt;location/&gt; matches, so we get a virtual presence service
The virtual presence server is address and a set of rules.
<code><![CDATA[location.virtual-presence.org]]></code> The virtual presence server is
</p>
The protocol to use is <code><![CDATA[location.virtual-presence.org]]></code>
<code><![CDATA[xmpp]]></code> <p>The protocol to use is</p>
<code><![CDATA[xmpp]]></code>
There mapping rule is: <p>There mapping rule is:</p>
<code><![CDATA[ <code><![CDATA[
match='^http://([^/]+)($|/.*$)' match='^http://([^/]+)($|/.*$)'
<name>\1</name> <name>\1</name>
<digest/>]]></code> <digest/>]]></code>
<p>
The result of the first phase is a mapping rule, which will be The result of the first phase is a mapping rule, which will be applied to
applied to all URLs <em>in the same folder</em> as the original URL. In regex-speech: all URLs <em>in the same folder</em> as the original URL.
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/.*]]></code> In regex-speech:
</p>
To apply the mask only to URLs in the same URL-path folder is a security <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/.*]]></code>
requirement, so that &apos;inner&apos; VPI files <p>
from websites can not configure the mapping of &apos;outer&apos; folders or &apos;siblings&apos;. To apply the mask only to URLs in the same URL-path folder is a security
</p> requirement, so that &apos;inner&apos; VPI files from websites can not
<p> configure the mapping of &apos;outer&apos; folders or
The original URL was: &apos;siblings&apos;.
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code> </p>
<p>The original URL was:</p>
So, the security mask is (the rule applies only to URLs in the same folder as the original URL): <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
<code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code> <p>
If the security mask applies to a URL can be verified by a simple string-compare without using a regular expression. So, the security mask is (the rule applies only to URLs in the same folder
</p> as the original URL):
<p> </p>
The &lt;location/&gt; has a match attribute. This is the user supplied mask <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code>
of the rule: <p>
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code> If the security mask applies to a URL can be verified by a simple
</p> string-compare without using a regular expression.
</p>
<p>
The &lt;location/&gt; has a match attribute.
This is the user supplied mask of the rule:
</p>
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
</section3> </section3>
<section3 topic='Apply the Rule'> <section3 topic='Apply the Rule'>
<p>The URL where we want to meet people is:</p>
<p>
The URL where we want to meet people is:
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
We got many rules with a security mask (from the folder of the original URL) and a regular expression
(from the match-attribute). For each new URl we check the URL against the security mask and the regular expression.
One of the rules applies to the URL:
<code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*
^http://([^/]+)($|/.*$)]]></code>
The regular expression
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
and the room &lt;name&gt;
<code><![CDATA[\1-room]]></code>
will extract the first level folder from the URL. The URL
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code> <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
<p>
gives: We got many rules with a security mask (from the folder of the original
URL) and a regular expression (from the match-attribute).
For each new URl we check the URL against the security mask and the
regular expression.
One of the rules applies to the URL:
</p>
<code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*
^http://([^/]+)($|/.*$)]]></code>
<p>The regular expression</p>
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
<p>and the room &lt;name&gt;</p>
<code><![CDATA[\1-room]]></code>
<p>will extract the first level folder from the URL. The URL</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
<p>gives:</p>
<code><![CDATA[market-room]]></code> <code><![CDATA[market-room]]></code>
<p>
The &lt;digest/&gt;-tag tells us to hash the regex replacement result with The &lt;digest/&gt;-tag tells us to hash the regex replacement result with
the default message digest SHA1. So we get: the default message digest SHA1. So we get:
</p>
<code><![CDATA[87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code> <code><![CDATA[87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
<p>The &lt;prefix/&gt;-tag tells us to prefix with</p>
The &lt;prefix/&gt;-tag tells us to prefix with
<code><![CDATA[vp-]]></code> <code><![CDATA[vp-]]></code>
<p>and finally the ID of the virtual location (the room name) is:</p>
and finally the ID of the virtual location (the room name) is:
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code> <code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
<p>From the &lt;service/&gt;</p>
From the &lt;service/&gt;
<code><![CDATA[xmpp:location.virtual-presence.org]]></code> <code><![CDATA[xmpp:location.virtual-presence.org]]></code>
<p>
the client knows the transport protocol and the address. The Jabber protocol will the client knows the transport protocol and the address. The Jabber
be used as transport protocol and the Jabber conference room JID is protocol will be used as transport protocol and the Jabber conference room
JID is
</p>
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3@location.virtual-presence.org]]></code> <code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3@location.virtual-presence.org]]></code>
</p>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -791,19 +783,21 @@ http://www.shakespeare.com/_vpi.xml]]>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations'> <section1 topic='XMPP Registrar Considerations'>
<p>These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document. <p>
<ul> These namespaces need to be reviewed and/or registered with the XMPP
<li>firebat:user:jid</li> Registrar as a result of this document:
<li>firebat:avatar:position</li>
<li>firebat:avatar:getpos</li>
<li>firebat:chat:state</li>
<li>firebat:icon:video</li>
<li>firebat:avatar:digest</li>
<li>firebat:avatar2:digest</li>
<li>storage:client:avatar</li>
<li>storage:client:avatar2</li>
</ul>
</p> </p>
<ul>
<li>firebat:user:jid</li>
<li>firebat:avatar:position</li>
<li>firebat:avatar:getpos</li>
<li>firebat:chat:state</li>
<li>firebat:icon:video</li>
<li>firebat:avatar:digest</li>
<li>firebat:avatar2:digest</li>
<li>storage:client:avatar</li>
<li>storage:client:avatar2</li>
</ul>
</section1> </section1>
<section1 topic='Formal Definition'> <section1 topic='Formal Definition'>
@ -815,14 +809,20 @@ http://www.shakespeare.com/_vpi.xml]]>
<section1 topic='Conclusion'> <section1 topic='Conclusion'>
<p>The virtual presence on Jabber has been designed to fit easily into the existing Jabber infrastructure including existing software components, clients, and protocols. It turns out that Jabber offers everything necessary for basic virtual presence. </p> <p>The virtual presence on Jabber has been designed to fit easily into the existing Jabber infrastructure including existing software components, clients, and protocols. It turns out that Jabber offers everything necessary for basic virtual presence. </p>
<p>This document proposes a mapping process in order to create a space for virtual presence on top of the URL based Web infrastructure. It also proposes namespace extensions for the protocol, which make virtual presence on web pages more convenient. The core features are: <p>
<ul> This document proposes a mapping process in order to create a space for
<li>URL mapping and service discovery,</li> virtual presence on top of the URL based Web infrastructure.
<li>avatars standing and walking on a web page,</li> It also proposes namespace extensions for the protocol, which make virtual
<li>bubble chat,</li> presence on web pages more convenient.
<li>iconic video.</li> The core features are:
</ul> </p>
There are definitely more features possible. Suggestions are welcome</p> <ul>
<li>URL mapping and service discovery,</li>
<li>avatars standing and walking on a web page,</li>
<li>bubble chat,</li>
<li>iconic video.</li>
</ul>
<p>There are definitely more features possible. Suggestions are welcome</p>
</section1> </section1>
</xep> </xep>

2
xep-0152.xml
View File

@ -254,7 +254,7 @@
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.</p> <p>Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.</p>
<t>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</t> <p>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>

12
xep-0157.xml
View File

@ -21,18 +21,18 @@
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>
&stpeter; &stpeter;
<revision>
<version>1.0</version>
<date>2007-01-31</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, advanced specification to Active.</p></remark>
</revision>
<author> <author>
<firstname>Jacek</firstname> <firstname>Jacek</firstname>
<surname>Konieczny</surname> <surname>Konieczny</surname>
<email>jajcus@jajcus.net</email> <email>jajcus@jajcus.net</email>
<jid>jajcus@jabber.bnet.pl</jid> <jid>jajcus@jabber.bnet.pl</jid>
</author> </author>
<revision>
<version>1.0</version>
<date>2007-01-31</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, advanced specification to Active.</p></remark>
</revision>
<revision> <revision>
<version>0.6</version> <version>0.6</version>
<date>2007-01-25</date> <date>2007-01-25</date>

4
xep-0162.xml
View File

@ -12,17 +12,17 @@
<number>0162</number> <number>0162</number>
<status>Deferred</status> <status>Deferred</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig>
<dependencies/> <dependencies/>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<sig>Standards</sig> <shortname>N/A</shortname>
<author> <author>
<firstname>Lucas</firstname> <firstname>Lucas</firstname>
<surname>Nussbaum</surname> <surname>Nussbaum</surname>
<email>lucas@lucas-nussbaum.net</email> <email>lucas@lucas-nussbaum.net</email>
<jid>lucas@nussbaum.fr</jid> <jid>lucas@nussbaum.fr</jid>
</author> </author>
<shortname>N/A</shortname>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<date>2005-12-06</date> <date>2005-12-06</date>

85
xep-0171.xml
View File

@ -177,10 +177,10 @@
<translation destination_lang='fr' source_lang='en'/> <translation destination_lang='fr' source_lang='en'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Translation With Pivot' anchor='message-pivot'> <section3 topic='Translation With Pivot' anchor='message-pivot'>
<p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no <x/> translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.</p> <p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no &lt;x/&gt; translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.</p>
<example caption='Entity sends a message translated from French to Russian via English using human translators'><![CDATA[ <example caption='Entity sends a message translated from French to Russian via English using human translators'><![CDATA[
<message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'> <message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
<subject xml:lang='fr'>Bonjour</subject> <subject xml:lang='fr'>Bonjour</subject>
@ -194,7 +194,7 @@
<translation destination_lang='ru' source_lang='en'/> <translation destination_lang='ru' source_lang='en'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Translation With Pivot Specifying Details' anchor='message-pivot-details'> <section3 topic='Translation With Pivot Specifying Details' anchor='message-pivot-details'>
<p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity using pivot languages and machine translation. The source language is known because there is no &X; translation tag describing it.</p> <p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity using pivot languages and machine translation. The source language is known because there is no &X; translation tag describing it.</p>
@ -212,7 +212,7 @@
<translation destination_lang='ru' engine='SYSTRANS' source_lang='en'/> <translation destination_lang='ru' engine='SYSTRANS' source_lang='en'/>
</x> </x>
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Discovering Translation Providers' anchor='disco'> <section2 topic='Discovering Translation Providers' anchor='disco'>
@ -222,7 +222,7 @@
<iq type='get' id='disco1' to='shakespeare.lit'> <iq type='get' id='disco1' to='shakespeare.lit'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Server returns items, including translation providers'><![CDATA[ <example caption='Server returns items, including translation providers'><![CDATA[
<iq type='result' id='disco1' from='shakespeare.lit' to='bard@shakespeare.lit/globe'> <iq type='result' id='disco1' from='shakespeare.lit' to='bard@shakespeare.lit/globe'>
<query xmlns='http://jabber.org/protocol/disco#items'> <query xmlns='http://jabber.org/protocol/disco#items'>
@ -234,7 +234,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Discovering Identity of Providers' anchor='disco-identity'> <section3 topic='Discovering Identity of Providers' anchor='disco-identity'>
<p>Service Discovery is used to determine if a JID provides translation services. The JID can also be a bot (e.g., &lt;towerofbabel@shakespeare.lit&gt;) or a server component (e.g., &lt;translation.shakespeare.lit&gt;).</p> <p>Service Discovery is used to determine if a JID provides translation services. The JID can also be a bot (e.g., &lt;towerofbabel@shakespeare.lit&gt;) or a server component (e.g., &lt;translation.shakespeare.lit&gt;).</p>
@ -242,7 +242,7 @@
<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'> <iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service reports identity'><![CDATA[ <example caption='Service reports identity'><![CDATA[
<iq type='result' to='bard@shakespeare.lit/globe' from='translation.shakespeare.lit'> <iq type='result' to='bard@shakespeare.lit/globe' from='translation.shakespeare.lit'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
@ -252,7 +252,7 @@
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Discovering Language Support' anchor='disco-lang'> <section3 topic='Discovering Language Support' anchor='disco-lang'>
<p>The supported languages and other details for the service must be known to use it. It is permissible for a translation service to provide multiple translation engines for the same language pairing -- if this is done, then a separate &lt;item/&gt; tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific &lt;item/&gt;. In order to specify more than one dictionary for a given language pairing then a separate &lt;item/&gt; tag MUST be used for each dictionary specification for that language pairing.</p> <p>The supported languages and other details for the service must be known to use it. It is permissible for a translation service to provide multiple translation engines for the same language pairing -- if this is done, then a separate &lt;item/&gt; tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific &lt;item/&gt;. In order to specify more than one dictionary for a given language pairing then a separate &lt;item/&gt; tag MUST be used for each dictionary specification for that language pairing.</p>
@ -260,27 +260,27 @@
<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'> <iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
<query xmlns='urn:xmpp:langtrans:items'/> <query xmlns='urn:xmpp:langtrans:items'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='Service replies with language details'><![CDATA[ <example caption='Service replies with language details'><![CDATA[
<iq type='result' to='bard@shakespeare.lit/globe' from=' translation.shakespeare.lit'> <iq type='result' to='bard@shakespeare.lit/globe' from=' translation.shakespeare.lit'>
<query xmlns='urn:xmpp:langtrans:items'> <query xmlns='urn:xmpp:langtrans:items'>
<item source_lang='en' jid='translation.shakespeare.lit' destination_lang='fr' <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='fr'
engine='SYSTRANS 2005 Release 2' pivotable='true'/> engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ko' <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ko'
engine='SYSTRANS 2005 Release 2' pivotable='true'/> engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru'
engine='SYSTRANS 2005 Release 2' pivotable='true'/> engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='medical'/> engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='medical'/>
<item source_lang='fr' jid='translation.shakespeare.lit' destination_lang='en' <item source_lang='fr' jid='translation.shakespeare.lit' destination_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='standard'/> engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='standard'/>
<item source_lang='ru' jid='translation.shakespeare.lit' destination_lang='en' <item source_lang='ru' jid='translation.shakespeare.lit' destination_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='Medical 1.0'/> engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='Medical 1.0'/>
<item source_lang='ko' jid='translation.shakespeare.lit' destination_lang='en' <item source_lang='ko' jid='translation.shakespeare.lit' destination_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true'/> engine='SYSTRANS 2005 Release 2' pivotable='true'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Requesting a Translation from a Service' anchor='request'> <section2 topic='Requesting a Translation from a Service' anchor='request'>
@ -293,8 +293,7 @@
<translation destination_lang='fr'/> <translation destination_lang='fr'/>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
<example caption='Translation is returned from translation provider'><![CDATA[ <example caption='Translation is returned from translation provider'><![CDATA[
<iq type='result' id='translationReq_2' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'> <iq type='result' id='translationReq_2' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'> <x xmlns='urn:xmpp:langtrans'>
@ -302,7 +301,7 @@
<translation destination_lang='fr' source_lang='en' engine='default'>comment allez-vous?</translation> <translation destination_lang='fr' source_lang='en' engine='default'>comment allez-vous?</translation>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Requesting a Translation With Multiple Destination Languages' anchor='request-multiple'> <section3 topic='Requesting a Translation With Multiple Destination Languages' anchor='request-multiple'>
<example caption='bard requests a translation from English to Italian and German'><![CDATA[ <example caption='bard requests a translation from English to Italian and German'><![CDATA[
@ -312,8 +311,8 @@
<translation destination_lang='it'/> <translation destination_lang='it'/>
<translation destination_lang='de'/> <translation destination_lang='de'/>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
<example caption='Translation is returned from translation provider'><![CDATA[ <example caption='Translation is returned from translation provider'><![CDATA[
<iq type='result' id='translationReq_4' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'> <iq type='result' id='translationReq_4' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'> <x xmlns='urn:xmpp:langtrans'>
@ -322,7 +321,7 @@
<translation destination_lang='de' source_lang='en' engine='default'>Wie geht es Ihnen?</translation> <translation destination_lang='de' source_lang='en' engine='default'>Wie geht es Ihnen?</translation>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Requesting a Translation With a Specific Dictionary' anchor='request-dictionary'> <section3 topic='Requesting a Translation With a Specific Dictionary' anchor='request-dictionary'>
<p>If a specific dictionary is required you MAY request a dictionary. This SHOULD have been returned when discoing the server although a dictionary MAY be requested which was not. The dictionaries are translation engine specific and are free form text.</p> <p>If a specific dictionary is required you MAY request a dictionary. This SHOULD have been returned when discoing the server although a dictionary MAY be requested which was not. The dictionaries are translation engine specific and are free form text.</p>
@ -333,20 +332,20 @@
<translation destination_lang='fr' dictionary='medical'/> <translation destination_lang='fr' dictionary='medical'/>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
<example caption='Translation provider returns translation with dictionary details'><![CDATA[ <example caption='Translation provider returns translation with dictionary details'><![CDATA[
<iq type='result' id='translationReq_6' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'> <iq type='result' id='translationReq_6' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'> <x xmlns='urn:xmpp:langtrans'>
<source xml:lang='en'>hello, how are you?</source> <source xml:lang='en'>hello, how are you?</source>
<translation <translation
destination_lang='fr' destination_lang='fr'
dictionary='medical' dictionary='medical'
engine='default' engine='default'
source_lang='en'>comment allez-vous?</translation> source_lang='en'>comment allez-vous?</translation>
</x> </x>
</iq> </iq>
]]></example> ]]></example>
<p>If the translation service cannot complete the translation it SHOULD return a <item-not-found/> error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.</p> <p>If the translation service cannot complete the translation it SHOULD return a &lt;item-not-found/&gt; error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.</p>
<example caption='Translation could not be completed'><![CDATA[ <example caption='Translation could not be completed'><![CDATA[
<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'> <iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'> <x xmlns='urn:xmpp:langtrans'>
@ -357,8 +356,8 @@
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>If privacy or security considerations make returning an <item-not-found/> error not feasible it SHOULD return a <service-unavailable/> error.</p> <p>If privacy or security considerations make returning an &lt;item-not-found/&gt; error not feasible it SHOULD return a &lt;service-unavailable/&gt; error.</p>
<example caption='Service unavailable'><![CDATA[ <example caption='Service unavailable'><![CDATA[
<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'> <iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'> <x xmlns='urn:xmpp:langtrans'>
@ -369,7 +368,7 @@
<service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/> <service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -408,11 +407,11 @@
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns='urn:xmpp:langtrans' xmlns='urn:xmpp:langtrans'
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:langtrans' targetNamespace='urn:xmpp:langtrans'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The protocol documented by this schema is defined in The protocol documented by this schema is defined in
@ -453,7 +452,7 @@
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='empty'> <xs:simpleType name='empty'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value=''/> <xs:enumeration value=''/>
@ -461,15 +460,15 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
<section2 topic='langtrans:items' anchor='schema-langtrans-items'> <section2 topic='langtrans:items' anchor='schema-langtrans-items'>
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns='urn:xmpp:langtrans:items' xmlns='urn:xmpp:langtrans:items'
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:langtrans:items' targetNamespace='urn:xmpp:langtrans:items'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:annotation> <xs:annotation>
@ -502,7 +501,7 @@
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='empty'> <xs:simpleType name='empty'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value=''/> <xs:enumeration value=''/>
@ -510,7 +509,7 @@
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
]]></code> ]]></code>
</section2> </section2>
</section1> </section1>
</xep> </xep>

1
xep-0179.xml
View File

@ -8,6 +8,7 @@
<header> <header>
<title>Jingle IAX Transport Method</title> <title>Jingle IAX Transport Method</title>
<abstract>This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication.</abstract> <abstract>This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication.</abstract>
&LEGALNOTICE;
<number>0179</number> <number>0179</number>
<status>Deferred</status> <status>Deferred</status>
<type>Standards Track</type> <type>Standards Track</type>

13
xep-0180.xml
View File

@ -7,7 +7,18 @@
<xep> <xep>
<header> <header>
<title>Jingle Video via RTP</title> <title>Jingle Video via RTP</title>
<abstract>This specification defines a Jingle application type for negotiating a video chat or other video session. The application type uses the Real-time Transport Protocol (RTP) for the underlying media exchange and provides a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints. <em>Note: This specification has been retracted in favor of XEP-0167, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification; please refer to XEP-0167 for the most up-to-date definition of XMPP video chat.</em></abstract> <abstract>
Note: This specification has been retracted in favor of XEP-0167, which now
consolidates both audio and video chat via RTP and therefore contains the
content originally published in this specification; please refer to XEP-0167
for the most up-to-date definition of XMPP video chat.
This specification defines a Jingle application type for negotiating a video
chat or other video session.
The application type uses the Real-time Transport Protocol (RTP) for the
underlying media exchange and provides a straightforward mapping to Session
Description Protocol (SDP) for interworking with SIP media endpoints.
</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0180</number> <number>0180</number>
<status>Retracted</status> <status>Retracted</status>

6
xep-0185.xml
View File

@ -35,22 +35,22 @@
</revision> </revision>
<revision> <revision>
<version>0.4</version> <version>0.4</version>
<initials>psa/ph</initials>
<date>2007-02-09</date> <date>2007-02-09</date>
<initials>psa/ph</initials>
<remark><p>Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.</p> <remark><p>Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.</p>
</remark> </remark>
</revision> </revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
<initials>ph</initials>
<date>2006-11-01</date> <date>2006-11-01</date>
<initials>ph</initials>
<remark><p>Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match revisions to RFC 3920.</p> <remark><p>Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match revisions to RFC 3920.</p>
</remark> </remark>
</revision> </revision>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<initials>ph</initials>
<date>2006-05-10</date> <date>2006-05-10</date>
<initials>ph</initials>
<remark> <remark>
<p>Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.</p> <p>Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.</p>
</remark> </remark>

2
xep.dtd
View File

@ -128,7 +128,7 @@ THE SOFTWARE.
<!ELEMENT acronym (#PCDATA)* > <!ELEMENT acronym (#PCDATA)* >
<!ELEMENT example (#PCDATA)* > <!ELEMENT example (#PCDATA)* >
<!ATTLIST example caption CDATA '' > <!ATTLIST example caption CDATA '' >
<!ELEMENT code (#PCDATA | span | em)* > <!ELEMENT code (#PCDATA | span | em | strong)* >
<!ATTLIST code caption CDATA '' > <!ATTLIST code caption CDATA '' >
<!ELEMENT table (tr)* > <!ELEMENT table (tr)* >
<!ATTLIST table caption CDATA '' > <!ATTLIST table caption CDATA '' >