<p>The Diffie-Hellman key agreement algorithm <ulinkurl="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’s identities, even when an active attacker exists.</p>
<p>This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) <ulinkurl="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27748789">[1]</ulink>and the OAKLEY key determination protocol<ulinkurl="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>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’s identities, even when an active attacker exists.</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>
<li>it uses weak address validation mechanism (cookies) to avoid denial of service attacks.
</li>
@ -387,8 +387,8 @@
@@ -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>
<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 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 <ulinkurl="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 RFC2406 <ulinkurl="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 <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>
<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>
<examplecaption='Partial escape sequence'><strong>\2plus\2is\4</strong> is not modified by escaping or unescaping transformations.</example>
<examplecaption='Invalid escape sequence 1'><strong>foo\bar</strong> is not modified (to <strong>fooºr</strong>) by escaping or unescaping transformations.</example>
<examplecaption='Invalid escape sequence 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) by escaping or unescaping transformations.</example>
<examplecaption='Partial escape sequence'>"\2plus\2is\4" is not modified by escaping or unescaping transformations.</example>
<examplecaption='Invalid escape sequence 1'>"foo\bar" is not modified (to "fooºr") by escaping or unescaping transformations.</example>
<examplecaption='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>
</section2>
<section2topic='JID Escaping vs. Older Methods'anchor='bizrules-othermethods'>
@ -156,7 +156,7 @@ Service | Manager
@@ -156,7 +156,7 @@ Service | Manager
<td>REQUIRED *</td>
</tr>
</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>
<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>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>
<section2topic='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 sample protocol flow for this use case is shown below.</p>
<p>When publishing a stream via the <sipub/> element, the identifier SHOULD NOT be used as-is for the <si/> element, since a single publication will likely result in multiple <si/> requests, possibly from the same receiver.</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
<ul>
<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>
</ul>
</p>
<p>This document describes protocol elements for:</p>
<ul>
<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>
</ul>
<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:
<ul>
<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 traffic generated.</li>
</ul>
</p>
<p>The extensions have been designed to be:</p>
<ul>
<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 traffic generated.</li>
</ul>
<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 @@
@@ -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 'interesting' 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
<ul>
<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
<ul>
<li>most URLs are path based,</li>
<li>URLs contain queries,</li>
<li>sometimes only the query part defines the virtual location,</li>
<li>groups of URLs map to a single JID,</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>not all URLs are known at config time,</li>
</ul>
</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>allow for hierarchical configuration for file system path based URLs,</li>
<li>support delegation,</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>support commercial virtual presence servers and rented rooms,</li>
<li>be extensible to other protocols as virtual presence transport,</li>
<li>be easily implemented by website operators,</li>
<li>at least limit the privacy issues associated with virtual presence.</li>
</ul>
</p>
<p>This mapping process is designed to:</p>
<ul>
<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
<ul>
<li>most URLs are path based,</li>
<li>URLs contain queries,</li>
<li>sometimes only the query part defines the virtual location,</li>
<li>groups of URLs map to a single JID,</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>not all URLs are known at config time,</li>
</ul>
</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>allow for hierarchical configuration for file system path based URLs,</li>
<li>support delegation,</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>support commercial virtual presence servers and rented rooms,</li>
<li>be extensible to other protocols as virtual presence transport,</li>
<li>be easily implemented by website operators,</li>
<li>at least limit the privacy issues associated with virtual presence.</li>
</ul>
</section2>
</section1>
@ -207,11 +203,8 @@
@@ -207,11 +203,8 @@
</section2>
<section2topic='Getting more information'>
<p>For more information about 'YoungHero' 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's client may use Juliet's actual JID. </p>
<p>Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.</p>
<examplecaption='Disclosing the JID'><![CDATA[
@ -224,13 +217,12 @@
@@ -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'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:
<ol>
<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>
</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>
<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>
<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>
</ol>
<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>
</section2>
@ -464,17 +456,14 @@ as part of:
@@ -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>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:
<ul>
<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>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 'Accept: image/djpeg' header to the HTTP request. (djpeg for differential JPEG)</li>
</ul>
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>
<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>
<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>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 'Accept: image/djpeg' header to the HTTP request. (djpeg for differential JPEG)</li>
</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>
We store the result in the cache and search for a matching <location/>
again. We find the default section (rest of the file omitted, the match-attribute is more general than the one of the previous <delegate/>, because here we are already in the .com domain):
<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:
<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>
There are definitely more features possible. Suggestions are welcome</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>
<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>
<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>
<section3topic='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 <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>
<examplecaption='Entity sends a message translated from French to Russian via English using human translators'><![CDATA[
<section3topic='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>
<section3topic='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., <towerofbabel@shakespeare.lit>) or a server component (e.g., <translation.shakespeare.lit>).</p>
<section3topic='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 <item/> tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific <item/>. In order to specify more than one dictionary for a given language pairing then a separate <item/> tag MUST be used for each dictionary specification for that language pairing.</p>
<translationdestination_lang='de'source_lang='en'engine='default'>Wie geht es Ihnen?</translation>
</x>
</iq>
]]></example>
]]></example>
</section3>
<section3topic='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 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>
]]></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>
<examplecaption='Translation could not be completed'><![CDATA[
<p>If privacy or security considerations make returning an <item-not-found/> error not feasible it SHOULD return a <service-unavailable/> error.</p>
]]></example>
<p>If privacy or security considerations make returning an <item-not-found/> error not feasible it SHOULD return a <service-unavailable/> error.</p>
<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 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.
Sam Whited
6 years ago