From 424dd6c59ba528f20658f3e85ebc1841d2ca65af Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sun, 1 Jan 2017 19:56:24 -0600 Subject: [PATCH] =?UTF-8?q?XEP-0101=E2=80=93XEP-0185:=20Fix=20DTD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- xep-0101.xml | 2 +- xep-0102.xml | 8 +- xep-0103.xml | 4 +- xep-0105.xml | 5 +- xep-0106.xml | 6 +- xep-0109.xml | 5 +- xep-0119.xml | 2 +- xep-0120.xml | 2 +- xep-0121.xml | 2 +- xep-0123.xml | 7 +- xep-0125.xml | 2 +- xep-0133.xml | 2 +- xep-0137.xml | 2 +- xep-0146.xml | 242 +++++++++++++++++------------------ xep-0151.xml | 354 +++++++++++++++++++++++++-------------------------- xep-0152.xml | 2 +- xep-0157.xml | 12 +- xep-0162.xml | 4 +- xep-0171.xml | 85 ++++++------- xep-0179.xml | 1 + xep-0180.xml | 13 +- xep-0185.xml | 6 +- xep.dtd | 2 +- 23 files changed, 396 insertions(+), 374 deletions(-) diff --git a/xep-0101.xml b/xep-0101.xml index 0e934832..5c0064de 100644 --- a/xep-0101.xml +++ b/xep-0101.xml @@ -13,11 +13,11 @@ Deferred Standards Track Standards - RFC 2616, RFC 2617, XEP-0030 XMPP Core RFC 2616 RFC 2617 + XEP-0030 diff --git a/xep-0102.xml b/xep-0102.xml index ed8d57eb..77b97f19 100644 --- a/xep-0102.xml +++ b/xep-0102.xml @@ -361,8 +361,8 @@ -

The Diffie-Hellman key agreement algorithm [10] 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.

-

This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) [1] and the OAKLEY key determination protocol [2]. 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:

+

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.

+

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:

  • it uses weak address validation mechanism (cookies) to avoid denial of service attacks.
    • @@ -387,8 +387,8 @@

    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.

    • 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.
      • -
    • 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 [3].
      • -
    • 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 [3].
      • +
    • 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;.
      • +
    • 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.
    • 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.
    diff --git a/xep-0103.xml b/xep-0103.xml index 6db98a09..ceaed949 100644 --- a/xep-0103.xml +++ b/xep-0103.xml @@ -132,8 +132,8 @@
  • Once retrieval is complete, the Receiver responds to Sender (EUC).
      • -
    • E1: The given URL is not supported/understood
      • -
    • E2: Failure to connect to the given URL
      • +
    • E1: The given URL is not supported/understood
      • +
    • E2: Failure to connect to the given URL

    The sender starts with an SI request, using the semantics from XEP-0095:

    Deferred Standards Track Standards - XEP-0095, XEP-0096 + + XEP-0095 + XEP-0096 + si-treetransfer diff --git a/xep-0106.xml b/xep-0106.xml index de3f7478..d36fd34a 100644 --- a/xep-0106.xml +++ b/xep-0106.xml @@ -204,9 +204,9 @@

    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').

    - \2plus\2is\4 is not modified by escaping or unescaping transformations. - foo\bar is not modified (to fooºr) by escaping or unescaping transformations. - foob\41r is not modified (to foobAr) by escaping or unescaping transformations. + "\2plus\2is\4" is not modified by escaping or unescaping transformations. + "foo\bar" is not modified (to "fooºr") by escaping or unescaping transformations. + "foob\41r" is not modified (to "foobAr") by escaping or unescaping transformations.

    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").

     diff --git a/xep-0109.xml b/xep-0109.xml index 45207211..18559fc9 100644 --- a/xep-0109.xml +++ b/xep-0109.xml @@ -13,7 +13,10 @@ Deferred Standards Track Standards - XEP-0060, XEP-0163 + + XEP-0060 + XEP-0163 + ooo diff --git a/xep-0119.xml b/xep-0119.xml index c4bd729d..f1778321 100644 --- a/xep-0119.xml +++ b/xep-0119.xml @@ -156,7 +156,7 @@ Service | Manager REQUIRED * -

    * Note: The User Avatar specification (XEP-0084) 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.

    +

    * Note: The User Avatar specification (XEP-0084) 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.

    Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:

    diff --git a/xep-0120.xml b/xep-0120.xml index 86471318..dba89d70 100644 --- a/xep-0120.xml +++ b/xep-0120.xml @@ -16,7 +16,7 @@ Retracted Standards Track Standards - XMPP Core + XMPP Core infobits diff --git a/xep-0121.xml b/xep-0121.xml index 41964bcd..cc23b4e7 100644 --- a/xep-0121.xml +++ b/xep-0121.xml @@ -16,7 +16,7 @@ Retracted Informational Standards - XEP-0120 + XEP-0120 N/A diff --git a/xep-0123.xml b/xep-0123.xml index 20ccb3ea..3b1c6345 100644 --- a/xep-0123.xml +++ b/xep-0123.xml @@ -16,7 +16,12 @@ Retracted Standards Track Standards - XMPP Core, XMPP IM, XEP-0030, XEP-0120 + + XMPP Core + XMPP IM + XEP-0030 + XEP-0120 + N/A diff --git a/xep-0125.xml b/xep-0125.xml index 8079a890..b082330c 100644 --- a/xep-0125.xml +++ b/xep-0125.xml @@ -16,7 +16,7 @@ Retracted Informational Standards - XEP-0120 + XEP-0120 N/A diff --git a/xep-0133.xml b/xep-0133.xml index f3ecb8eb..33d30781 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -132,7 +132,7 @@
  • Shut Down Service

    • 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.

    -

    Note: The text that follows assumes that implementors have read and understood XEP-0050: Ad-Hoc Commands and XEP-0004: Data Forms.

    +

    Note: The text that follows assumes that implementors have read and understood XEP-0050: Ad-Hoc Commands and XEP-0004: Data Forms.

    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".

    A sample protocol flow for this use case is shown below.

    diff --git a/xep-0137.xml b/xep-0137.xml index f59c359a..3212e76c 100644 --- a/xep-0137.xml +++ b/xep-0137.xml @@ -237,7 +237,7 @@ ]]>     - +

    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.

     diff --git a/xep-0146.xml b/xep-0146.xml index 7333eacb..d1b6f8f3 100644 --- a/xep-0146.xml +++ b/xep-0146.xml @@ -226,25 +226,29 @@ -

    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).

    - +

    + 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). +

    +

    For example, suppose Romeo sends a message to Juliet, thinking she is - still on her balcony. The balcony client receives the message: - + - Just saying hi - Hello Juliet! - - ]]> - + Just saying hi + Hello Juliet! +]]> +

    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. - - + - - ]]> - +]]> +

    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. - + Just saying hi Hello Juliet!

    - + - - ]]> - - ]]> + - - - ]]> - - 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. + +]]> +

    + 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. +

    -

    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. -

    - + 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. +

    + - - - ]]> -

    Unless an error occurs (see the - Error Handling section below), the service - SHOULD return the appropriate form.

    - - + +]]> +

    + Unless an error occurs (see the Error + Handling section below), the service SHOULD return the + appropriate form. +

    + + node='http://jabber.org/protocol/rc#set-options' + sessionid='set-options:20040727T0337Z' + status='executing'> Set Options Set the desired options http://jabber.org/protocol/rc - + 1 + type='boolean' + var='auto-offline'> 0 + type='boolean' + var='auto-msg'> 0 + type='boolean' + var='auto-files'> 0 + type='boolean' + var='auto-auth'> 0 - - ]]> - ]]> + + to='juliet@example.com/balcony' + type='set' + id='set-options-2' + xml:lang='en'> + node='http://jabber.org/protocol/rc#set-options' + sessionid='set-options:20040727T0337Z'> http://jabber.org/protocol/rc @@ -392,30 +394,30 @@ - ]]> -

    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.

    - - +

    + 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. +

    + - - - ]]> -

    Notification of completion MAY include the processed data in a data - form of type 'result'.

    + +]]>     +

    + Notification of completion MAY include the processed data in a data form + of type 'result'. +

    - - - - - ]]> -

    Unless an error occurs (see the - Error Handling section below), the service - SHOULD return the appropriate form.

    - +]]> +

    + Unless an error occurs (see the Error Handling + section below), the service SHOULD return the appropriate form. +

    + - - ]]> +]]>     - - ]]> - - The remote client accepts the selected file transfers, and informs - the local client of completion. +]]> +

    + The remote client accepts the selected file transfers, and informs the + local client of completion. +

    - - ]]> +]]> diff --git a/xep-0151.xml b/xep-0151.xml index d8bc5204..3422c183 100644 --- a/xep-0151.xml +++ b/xep-0151.xml @@ -105,22 +105,20 @@

    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.

    -

    This document describes protocol elements for -

      -
    • the visualization of users on web pages (animated avatars) and
      • -
    • communication beyond line based group chat (incremental or instant bubble chat)
      • -
    -

    +

    This document describes protocol elements for:

    +
      +
    • the visualization of users on web pages (animated avatars) and
      • +
    • communication beyond line based group chat (incremental or instant bubble chat)
      • +

    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.

    -

    The extensions have been designed to be: -

      -
    • compatible to the existing Jabber infrastructure and protocols,
      • -
    • lightweight with respect to the number of new elements,
      • -
    • lightweight with respect to the traffic generated.
      • -
    -

    +

    The extensions have been designed to be:

    +
      +
    • compatible to the existing Jabber infrastructure and protocols,
      • +
    • lightweight with respect to the number of new elements,
      • +
    • lightweight with respect to the traffic generated.
      • +

    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.

    @@ -146,33 +144,31 @@

    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.

    -

    This mapping process is designed to -

      -
    • make the virtual presence service a distributed network of jabber servers, i.e. conference components,
      • -
    • allow for flexible mapping from URLs to JIDs, taking into account that -
        -
      • most URLs are path based,
        • -
      • URLs contain queries,
        • -
      • sometimes only the query part defines the virtual location,
        • -
      • groups of URLs map to a single JID,
        • -
      • a single virtual location may comprise multiple web servers,
        • -
      • groups of URLs may only cover a sub-folder of path based URLs,
        • -
      • not all URLs are known at config time,
        • -
      -
      • -
    • allow operators of websites to control the mapping for the URL-space they control,
      • -
    • let websites opt out of virtual presence,
      • -
    • allow for hierarchical configuration for file system path based URLs,
      • -
    • support delegation,
      • -
    • allow for virtual presence without the cooperation of the website,
      • -
    • allow for distribution of the load of the default configuration server,
      • -
    • support commercial virtual presence servers and rented rooms,
      • -
    • be extensible to other protocols as virtual presence transport,
      • -
    • be easily implemented by website operators,
      • -
    • at least limit the privacy issues associated with virtual presence.
      • -
    -

    - +

    This mapping process is designed to:

    +
      +
    • make the virtual presence service a distributed network of jabber servers, i.e. conference components,
      • +
    • allow for flexible mapping from URLs to JIDs, taking into account that +
        +
      • most URLs are path based,
        • +
      • URLs contain queries,
        • +
      • sometimes only the query part defines the virtual location,
        • +
      • groups of URLs map to a single JID,
        • +
      • a single virtual location may comprise multiple web servers,
        • +
      • groups of URLs may only cover a sub-folder of path based URLs,
        • +
      • not all URLs are known at config time,
        • +
      +
      • +
    • allow operators of websites to control the mapping for the URL-space they control,
      • +
    • let websites opt out of virtual presence,
      • +
    • allow for hierarchical configuration for file system path based URLs,
      • +
    • support delegation,
      • +
    • allow for virtual presence without the cooperation of the website,
      • +
    • allow for distribution of the load of the default configuration server,
      • +
    • support commercial virtual presence servers and rented rooms,
      • +
    • be extensible to other protocols as virtual presence transport,
      • +
    • be easily implemented by website operators,
      • +
    • at least limit the privacy issues associated with virtual presence.
      • +
    @@ -207,11 +203,8 @@ -

    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.

    -

    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.

    -

    Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.

    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.

    -

    Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons: -

      -
    1. to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,
      2. -
    2. to allow for caching of extended information.
      3. -
    - 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. -

    +

    Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons:

    +
      +
    1. to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,
      2. +
    2. to allow for caching of extended information.
      3. +
    +

    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.

     @@ -464,17 +456,14 @@ as part of:

    The video format is the common, widely used webcam format introduced by Netscape (JPEG server-pushed).

    -

    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: -

      -
    • video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,
      • -
    • 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),
      • -
    • 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,
      • -
    • 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)
      • -
    - - 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. -

    - +

    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:

    +
      +
    • video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,
      • +
    • 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),
      • +
    • 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,
      • +
    • 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)
      • +
    +

    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.

    @@ -626,29 +615,29 @@ http://www.shakespeare.com/_vpi.xml]]>

    This section is intended as a guideline for the implementation of the mapping process.

    -

    The mapping has 2 phases: -

      +

      The mapping has 2 phases:

      +
      1. finding the rule
      2. applying the rule
        3. -
      -

      +
    -

    - We get a URL from the web browser, say - - We try to fetch the configuration file from - - The request fails (the failure is noted in the cache), and we try - - The request fails again (the failure is noted in the cache). We try - - 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) - - The request returns (and the data is stored in the cache): - We get a URL from the web browser, say:

    + +

    We try to fetch the configuration file from

    + +

    The request fails (the failure is noted in the cache), and we try

    + +

    The request fails again (the failure is noted in the cache). We try

    + +

    + 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) +

    + +

    The request returns (and the data is stored in the cache):

    + @@ -670,20 +659,25 @@ http://www.shakespeare.com/_vpi.xml]]> ]]> - - We try to find a <location/> that matches our URL. We find: - We try to find a <location/> that matches our URL. We find:

    + http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml ]]> - This means that all .com domains are forwarded to a separate VPI file. +

    + This means that all .com domains are forwarded to a separate VPI file. We fetch: - - - 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): - + +

    + 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): +

    + xmpp:location.virtual-presence.org @@ -693,90 +687,88 @@ http://www.shakespeare.com/_vpi.xml]]> ...]]> - The <location/> matches, so we get a virtual presence - service address and a set of rules. - The virtual presence server is - - - The protocol to use is - - - There mapping rule is: - + The <location/> matches, so we get a virtual presence service + address and a set of rules. + The virtual presence server is +

    + +

    The protocol to use is

    + +

    There mapping rule is:

    + \1 ]]> - - The result of the first phase is a mapping rule, which will be - applied to all URLs in the same folder as the original URL. In regex-speech: - - - To apply the mask only to URLs in the same URL-path folder is a security - requirement, so that 'inner' VPI files - from websites can not configure the mapping of 'outer' folders or 'siblings'. -

    -

    - The original URL was: - - - So, the security mask is (the rule applies only to URLs in the same folder as the original URL): - - If the security mask applies to a URL can be verified by a simple string-compare without using a regular expression. -

    -

    - The <location/> has a match attribute. This is the user supplied mask - of the rule: - -

    +

    + The result of the first phase is a mapping rule, which will be applied to + all URLs in the same folder as the original URL. + In regex-speech: +

    + +

    + To apply the mask only to URLs in the same URL-path folder is a security + requirement, so that 'inner' VPI files from websites can not + configure the mapping of 'outer' folders or + 'siblings'. +

    +

    The original URL was:

    + +

    + So, the security mask is (the rule applies only to URLs in the same folder + as the original URL): +

    + +

    + If the security mask applies to a URL can be verified by a simple + string-compare without using a regular expression. +

    +

    + The <location/> has a match attribute. + This is the user supplied mask of the rule: +

    +     - -

    - - The URL where we want to meet people is: - - - 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: - - - The regular expression - - - and the room <name> - - - will extract the first level folder from the URL. The URL +

    The URL where we want to meet people is:

    - - 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: +

    + +

    The regular expression

    + +

    and the room <name>

    + +

    will extract the first level folder from the URL. The URL

    + +

    gives:

    - - The <digest/>-tag tells us to hash the regex replacement result with - the default message digest SHA1. So we get: +

    + The <digest/>-tag tells us to hash the regex replacement result with + the default message digest SHA1. So we get: +

    - - The <prefix/>-tag tells us to prefix with +

    The <prefix/>-tag tells us to prefix with

    - - and finally the ID of the virtual location (the room name) is: +

    and finally the ID of the virtual location (the room name) is:

    - - From the <service/> +

    From the <service/>

    - - 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 +

    + 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 +

    - -

    -     - @@ -791,19 +783,21 @@ http://www.shakespeare.com/_vpi.xml]]> -

    These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document. -

      -
    • firebat:user:jid
      • -
    • firebat:avatar:position
      • -
    • firebat:avatar:getpos
      • -
    • firebat:chat:state
      • -
    • firebat:icon:video
      • -
    • firebat:avatar:digest
      • -
    • firebat:avatar2:digest
      • -
    • storage:client:avatar
      • -
    • storage:client:avatar2
      • -
    +

    + These namespaces need to be reviewed and/or registered with the XMPP + Registrar as a result of this document:

    +
      +
    • firebat:user:jid
      • +
    • firebat:avatar:position
      • +
    • firebat:avatar:getpos
      • +
    • firebat:chat:state
      • +
    • firebat:icon:video
      • +
    • firebat:avatar:digest
      • +
    • firebat:avatar2:digest
      • +
    • storage:client:avatar
      • +
    • storage:client:avatar2
      • +
    @@ -815,14 +809,20 @@ http://www.shakespeare.com/_vpi.xml]]>

    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.

    -

    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: -

      -
    • URL mapping and service discovery,
      • -
    • avatars standing and walking on a web page,
      • -
    • bubble chat,
      • -
    • iconic video.
      • -
    - There are definitely more features possible. Suggestions are welcome

    +

    + 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: +

    +
      +
    • URL mapping and service discovery,
      • +
    • avatars standing and walking on a web page,
      • +
    • bubble chat,
      • +
    • iconic video.
      • +
    +

    There are definitely more features possible. Suggestions are welcome

     diff --git a/xep-0152.xml b/xep-0152.xml index 112223d7..109ab331 100644 --- a/xep-0152.xml +++ b/xep-0152.xml @@ -254,7 +254,7 @@

    Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.

    - 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. +

    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.

     diff --git a/xep-0157.xml b/xep-0157.xml index 84ff4432..f1e15e57 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -21,18 +21,18 @@ N/A &stpeter; - - 1.0 - 2007-01-31 - psa -

    Per a vote of the XMPP Council, advanced specification to Active.

     -     Jacek Konieczny jajcus@jajcus.net jajcus@jabber.bnet.pl + + 1.0 + 2007-01-31 + psa +

    Per a vote of the XMPP Council, advanced specification to Active.

     +     0.6 2007-01-25 diff --git a/xep-0162.xml b/xep-0162.xml index a87a7715..e28be7a7 100644 --- a/xep-0162.xml +++ b/xep-0162.xml @@ -12,17 +12,17 @@ 0162 Deferred Informational + Standards - Standards + N/A Lucas Nussbaum lucas@lucas-nussbaum.net lucas@nussbaum.fr - N/A 0.2 2005-12-06 diff --git a/xep-0171.xml b/xep-0171.xml index 34ed857f..56b0db5f 100644 --- a/xep-0171.xml +++ b/xep-0171.xml @@ -177,10 +177,10 @@ - ]]> +]]> -

    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 translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.

    +

    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.

    Bonjour @@ -194,7 +194,7 @@ - ]]> +]]>

    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.

    @@ -212,7 +212,7 @@ - ]]> +]]>     @@ -222,7 +222,7 @@ - ]]> +]]> @@ -234,7 +234,7 @@ ... - ]]> +]]>

    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>).

    @@ -242,7 +242,7 @@ - ]]> +]]> @@ -252,7 +252,7 @@ ... - ]]> +]]>

    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.

    @@ -260,27 +260,27 @@ - ]]> +]]> - - - - - - - - ]]> +]]>     @@ -293,8 +293,7 @@ - ]]> - +]]> @@ -302,7 +301,7 @@ comment allez-vous? - ]]> +]]> - - ]]> + +]]> @@ -322,7 +321,7 @@ Wie geht es Ihnen? - ]]> +]]>

    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.

    @@ -333,20 +332,20 @@ - ]]> +]]> hello, how are you? - comment allez-vous? - ]]> -

    If the translation service cannot complete the translation it SHOULD return a 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.

    +]]> +

    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.

    @@ -357,8 +356,8 @@ - ]]> -

    If privacy or security considerations make returning an error not feasible it SHOULD return a error.

    +]]> +

    If privacy or security considerations make returning an <item-not-found/> error not feasible it SHOULD return a <service-unavailable/> error.

    @@ -369,7 +368,7 @@ - ]]> +]]>     @@ -408,11 +407,11 @@ - + The protocol documented by this schema is defined in @@ -453,7 +452,7 @@ - + @@ -461,15 +460,15 @@ - ]]> +]]>     @@ -502,7 +501,7 @@ - + @@ -510,7 +509,7 @@ - ]]> +]]>     diff --git a/xep-0179.xml b/xep-0179.xml index cd3537ad..5ca9fc04 100644 --- a/xep-0179.xml +++ b/xep-0179.xml @@ -8,6 +8,7 @@
    Jingle IAX Transport Method This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication. + &LEGALNOTICE; 0179 Deferred Standards Track diff --git a/xep-0180.xml b/xep-0180.xml index 5ef5498f..e73f8085 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -7,7 +7,18 @@
    Jingle Video via RTP - 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. 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. + + 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. + &LEGALNOTICE; 0180 Retracted diff --git a/xep-0185.xml b/xep-0185.xml index 134e83d3..6e55e524 100644 --- a/xep-0185.xml +++ b/xep-0185.xml @@ -35,22 +35,22 @@ 0.4 - psa/ph 2007-02-09 + psa/ph

    Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.

         0.3 - ph 2006-11-01 + ph

    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.

         0.2 - ph 2006-05-10 + ph

    Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.

     diff --git a/xep.dtd b/xep.dtd index f3306dd4..9aade7e4 100644 --- a/xep.dtd +++ b/xep.dtd @@ -128,7 +128,7 @@ THE SOFTWARE. - +