moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 01:32:22 -05:00
Code Issues Releases Wiki Activity

XEP-0101–XEP-0185: Fix DTD

Browse Source
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>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>RFC 2616, RFC 2617, XEP-0030</dependencies>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 2616</spec>
<spec>RFC 2617</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>

8
xep-0102.xml
View File

@ -361,8 +361,8 @@
</section1>
<section1 topic="Authenticated Key Agreement">
<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>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>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) 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 @@
<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 <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 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 <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>
</ul>
</section2>

4
xep-0103.xml
View File

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

5
xep-0105.xml
View File

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

6
xep-0106.xml
View File

@ -204,9 +204,9 @@
</section2>
<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>
<example caption='Partial escape sequence'><strong>\2plus\2is\4</strong> 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 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) 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'>"foo\bar" is not modified (to "foo&#186;r") 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>
</section2>
<section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>

5
xep-0109.xml
View File

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

2
xep-0119.xml
View File

@ -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>
</section1>
<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>

2
xep-0120.xml
View File

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

2
xep-0121.xml
View File

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

7
xep-0123.xml
View File

@ -16,7 +16,12 @@
<status>Retracted</status>
<type>Standards Track</type>
<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/>
<supersededby/>
<shortname>N/A</shortname>

2
xep-0125.xml
View File

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

2
xep-0133.xml
View File

@ -132,7 +132,7 @@
<li>Shut Down Service</li>
</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><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'>
<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>

2
xep-0137.xml
View File

@ -237,7 +237,7 @@
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' achor='impl-notes'>
<section1 topic='Implementation Notes' anchor='impl-notes'>
<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>
</section2>

126
xep-0146.xml
View File

@ -226,24 +226,28 @@
<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
the 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>
A user might want to forward all the unread messages residing at the
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
still on her balcony. The balcony client receives the message:
still on her balcony.
The balcony client receives the message:
</p>
<example caption='Remote Client Receives Message'><![CDATA[
<message from='romeo@example.com/orchard'
to='juliet@example.com/balcony'>
<subject>Just saying hi</subject>
<body>Hello Juliet!</body>
</message>
]]></example>
</message>]]></example>
<p>
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
request to the remote client to forward all unread messages.
(yet).
Realizing she left her balcony client unattended, she sends a request to
the remote client to forward all unread messages.
</p>
<example caption='Local Client Requests to Forward Unread Messages Currently Residing at the Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony'
@ -254,14 +258,14 @@
action='execute'
node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z'/>
</iq>
]]></example>
</iq>]]></example>
<p>
The client forwards all unread messages to the local client, adding
information about the origin of the message (using the 'ofrom'
&xep0033; address, and the &xep0203; timestamp of the original message).
The chamber client receives both these messages and a
confirmation that the command was completed.
information about the origin of the message (using the 'ofrom' &xep0033;
address, and the &xep0203; timestamp of the original message).
The chamber client receives both these messages and a confirmation that
the command was completed.
</p>
<example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
<message from='juliet@example.com/balcony'
to='juliet@example.com/chamber'>
@ -273,9 +277,7 @@
<delay xmlns='urn:xmpp:delay'
from='juliet@capulet.com/balcony'
stamp='2002-09-10T23:41:07Z'/>
</message>
]]></example>
</message>]]></example>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
@ -286,20 +288,21 @@
node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z'
status='completed'/>
</iq>
]]></example>
</iq>]]></example>
<p>
A client MAY provide a more fine-grained implementation, e.g. by
presenting the requester an extra form to select which messages
have to be forwarded.
presenting the requester an extra form to select which messages have to
be forwarded.
</p>
</section2>
<section2 topic='Change Run-Time Options'>
<p>It might be desirable to remotely set some run-time options of
a client. For example, when neighbours complain about the sounds your
client makes while you're at another location, you could turn the
sounds off at the remote client.
<p>
It might be desirable to remotely set some run-time options of a client.
For example, when neighbours complain about the sounds your client makes
while you're at another location, you could turn the sounds off at the
remote client.
</p>
<example caption='Local Client Requests to Change Options of a Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
@ -310,12 +313,12 @@
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#set-options'/>
</iq>
]]></example>
<p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p>
</iq>]]></example>
<p>
Unless an error occurs (see the <link url='#errors'>Error
Handling</link> section below), the service SHOULD return the
appropriate form.
</p>
<example caption='Remote Client Replies with a Form to Set its Options'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
@ -359,8 +362,7 @@
</field>
</x>
</command>
</iq>
]]></example>
</iq>]]></example>
<example caption='Local Client Submits Set Options Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony'
@ -393,10 +395,12 @@
</command>
</iq>
]]></example>
<p>The remote client sets the values of the options to their requested
value. If a variable is omitted, the client SHOULD NOT change the value of the
corresponding option.</p>
<p>
The remote client sets the values of the options to their requested
value.
If a variable is omitted, the client SHOULD NOT change the value of the
corresponding option.
</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
@ -407,15 +411,13 @@
node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z'
status='completed'/>
</iq>
]]></example>
<p>Notification of completion MAY include the processed data in a data
form of type 'result'.</p>
</iq>]]></example>
<p>
Notification of completion MAY include the processed data in a data form
of type 'result'.
</p>
</section2>
<!-- ************************************************************************ -->
<section2 topic='Accept Pending File Transfer Requests'>
<example caption='Local Client Requests to Accept Pending File Transfer Requests on the Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
@ -426,11 +428,11 @@
<command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#accept-files'/>
</iq>
]]></example>
<p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p>
</iq>]]></example>
<p>
Unless an error occurs (see the <link url='#errors'>Error Handling</link>
section below), the service SHOULD return the appropriate form.
</p>
<example caption='Remote Client Replies with a Form Containing Pending File Transfers'><![CDATA[
<iq from='juliet@example.com/balcony'
@ -464,8 +466,7 @@
</field>
</x>
</command>
</iq>
]]></example>
</iq>]]></example>
<example caption='Local Client Submits Form to Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
to='juliet@example.com/balcony'
@ -484,11 +485,11 @@
</field>
</x>
</command>
</iq>
]]></example>
The remote client accepts the selected file transfers, and informs
the local client of completion.
</iq>]]></example>
<p>
The remote client accepts the selected file transfers, and informs the
local client of completion.
</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
<iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
@ -499,8 +500,7 @@
node='http://jabber.org/protocol/rc#accept-files'
sessionid='accept-files:20040727T0337Z'
status='completed'/>
</iq>
]]></example>
</iq>]]></example>
</section2>

180
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>This document describes protocol elements for
<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>
<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>
<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 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,7 +144,7 @@
<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>
<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
@ -171,8 +169,6 @@
<li>be easily implemented by website operators,</li>
<li>at least limit the privacy issues associated with virtual presence.</li>
</ul>
</p>
</section2>
</section1>
@ -207,11 +203,8 @@
</section2>
<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>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>
<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>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>
<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>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:
<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>
<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 &apos;Accept: image/djpeg&apos; 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>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>
</section1>
@ -626,28 +615,28 @@ http://www.shakespeare.com/_vpi.xml]]>
<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>
<li>finding the rule</li>
<li>applying the rule</li>
</ol>
</p>
<section3 topic='Find the Rule'>
<p>
We get a URL from the web browser, say
<p>We get a URL from the web browser, say:</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
We try to fetch the configuration file from
<p>We try to fetch the configuration file from</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/_vpi.xml]]></code>
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</p>
<code><![CDATA[http://www.shakespeare.com/market/_vpi.xml]]></code>
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</p>
<code><![CDATA[http://www.shakespeare.com/_vpi.xml]]></code>
We do not find it (the failure is noted in the cache), and we revert to the
global file (which one depends on the client configuration)
<p>
We do not find it (the failure is noted in the cache), and we revert to
the global file (which one depends on the client configuration)
</p>
<code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml]]></code>
The request returns (and the data is stored in the cache):
<p>The request returns (and the data is stored in the cache):</p>
<code><![CDATA[
<?xml version='1.0' ?>
<vpi xmlns='http://schema.bluehands.de/virtual-presence-info'>
@ -670,19 +659,24 @@ http://www.shakespeare.com/_vpi.xml]]>
<digest/>
</location>
</vpi>]]></code>
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:</p>
<code><![CDATA[
<location match='^http://.*\.com/.*'>
<delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
</location>]]></code>
<p>
This means that all .com domains are forwarded to a separate VPI file.
We fetch:
</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;
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>
We store the result in the cache and search for a matching
&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://([^/]+)($|/.*$)'>
@ -693,90 +687,88 @@ http://www.shakespeare.com/_vpi.xml]]>
</location>
...]]></code>
The &lt;location/&gt; matches, so we get a virtual presence
service address and a set of rules.
<p>
The &lt;location/&gt; matches, so we get a virtual presence service
address and a set of rules.
The virtual presence server is
</p>
<code><![CDATA[location.virtual-presence.org]]></code>
The protocol to use is
<p>The protocol to use is</p>
<code><![CDATA[xmpp]]></code>
There mapping rule is:
<p>There mapping rule is:</p>
<code><![CDATA[
match='^http://([^/]+)($|/.*$)'
<name>\1</name>
<digest/>]]></code>
The result of the first phase is a mapping rule, which will be
applied to all URLs <em>in the same folder</em> as the original URL. In regex-speech:
<p>
The result of the first phase is a mapping rule, which will be applied to
all URLs <em>in the same folder</em> as the original URL.
In regex-speech:
</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/.*]]></code>
<p>
To apply the mask only to URLs in the same URL-path folder is a security
requirement, so that &apos;inner&apos; VPI files
from websites can not configure the mapping of &apos;outer&apos; folders or &apos;siblings&apos;.
requirement, so that &apos;inner&apos; VPI files from websites can not
configure the mapping of &apos;outer&apos; folders or
&apos;siblings&apos;.
</p>
<p>
The original URL was:
<p>The original URL was:</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
So, the security mask is (the rule applies only to URLs in the same folder as the original URL):
<p>
So, the security mask is (the rule applies only to URLs in the same folder
as the original URL):
</p>
<code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code>
If the security mask applies to a URL can be verified by a simple string-compare without using a regular expression.
<p>
If the security mask applies to a URL can be verified by a simple
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:
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
The &lt;location/&gt; has a match attribute.
This is the user supplied mask of the rule:
</p>
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
</section3>
<section3 topic='Apply the Rule'>
<p>
The URL where we want to meet people is:
<p>The URL where we want to meet people is:</p>
<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.
<p>
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>
The regular expression
<p>The regular expression</p>
<code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
and the room &lt;name&gt;
<p>and the room &lt;name&gt;</p>
<code><![CDATA[\1-room]]></code>
will extract the first level folder from the URL. The URL
<p>will extract the first level folder from the URL. The URL</p>
<code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
gives:
<p>gives:</p>
<code><![CDATA[market-room]]></code>
<p>
The &lt;digest/&gt;-tag tells us to hash the regex replacement result with
the default message digest SHA1. So we get:
<code><![CDATA[87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
The &lt;prefix/&gt;-tag tells us to prefix with
<code><![CDATA[vp-]]></code>
and finally the ID of the virtual location (the room name) is:
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
From the &lt;service/&gt;
<code><![CDATA[xmpp:location.virtual-presence.org]]></code>
the client knows the transport protocol and the address. The Jabber protocol will
be used as transport protocol and the Jabber conference room JID is
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3@location.virtual-presence.org]]></code>
</p>
<code><![CDATA[87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
<p>The &lt;prefix/&gt;-tag tells us to prefix with</p>
<code><![CDATA[vp-]]></code>
<p>and finally the ID of the virtual location (the room name) is:</p>
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
<p>From the &lt;service/&gt;</p>
<code><![CDATA[xmpp:location.virtual-presence.org]]></code>
<p>
the client knows the transport protocol and the address. The Jabber
protocol will be used as transport protocol and the Jabber conference room
JID is
</p>
<code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3@location.virtual-presence.org]]></code>
</section3>
</section2>
</section1>
@ -791,7 +783,10 @@ http://www.shakespeare.com/_vpi.xml]]>
</section1>
<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>
These namespaces need to be reviewed and/or registered with the XMPP
Registrar as a result of this document:
</p>
<ul>
<li>firebat:user:jid</li>
<li>firebat:avatar:position</li>
@ -803,7 +798,6 @@ http://www.shakespeare.com/_vpi.xml]]>
<li>storage:client:avatar</li>
<li>storage:client:avatar2</li>
</ul>
</p>
</section1>
<section1 topic='Formal Definition'>
@ -815,14 +809,20 @@ http://www.shakespeare.com/_vpi.xml]]>
<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>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>
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>
There are definitely more features possible. Suggestions are welcome</p>
<p>There are definitely more features possible. Suggestions are welcome</p>
</section1>
</xep>

2
xep-0152.xml
View File

@ -254,7 +254,7 @@
<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>
<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 topic='IANA Considerations' anchor='iana'>

12
xep-0157.xml
View File

@ -21,18 +21,18 @@
<supersededby/>
<shortname>N/A</shortname>
&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>
<firstname>Jacek</firstname>
<surname>Konieczny</surname>
<email>jajcus@jajcus.net</email>
<jid>jajcus@jabber.bnet.pl</jid>
</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>
<version>0.6</version>
<date>2007-01-25</date>

4
xep-0162.xml
View File

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

7
xep-0171.xml
View File

@ -180,7 +180,7 @@
]]></example>
</section3>
<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[
<message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
<subject xml:lang='fr'>Bonjour</subject>
@ -294,7 +294,6 @@
</x>
</iq>
]]></example>
<example caption='Translation is returned from translation provider'><![CDATA[
<iq type='result' id='translationReq_2' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'>
@ -346,7 +345,7 @@
</x>
</iq>
]]></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[
<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'>
@ -358,7 +357,7 @@
</error>
</iq>
]]></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[
<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
<x xmlns='urn:xmpp:langtrans'>

1
xep-0179.xml
View File

@ -8,6 +8,7 @@
<header>
<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>
&LEGALNOTICE;
<number>0179</number>
<status>Deferred</status>
<type>Standards Track</type>

13
xep-0180.xml
View File

@ -7,7 +7,18 @@
<xep>
<header>
<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;
<number>0180</number>
<status>Retracted</status>

6
xep-0185.xml
View File

@ -35,22 +35,22 @@
</revision>
<revision>
<version>0.4</version>
<initials>psa/ph</initials>
<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>
</revision>
<revision>
<version>0.3</version>
<initials>ph</initials>
<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>
</revision>
<revision>
<version>0.2</version>
<initials>ph</initials>
<date>2006-05-10</date>
<initials>ph</initials>
<remark>
<p>Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.</p>
</remark>

2
xep.dtd
View File

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