From 6464a63154cdab2a7ac2b00e7b8e2435b3397e69 Mon Sep 17 00:00:00 2001 From: stpeter Date: Wed, 31 Aug 2011 12:57:31 -0600 Subject: [PATCH] 0.7 --- xep-0260.xml | 35 ++++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/xep-0260.xml b/xep-0260.xml index 297ca9a4..7b68f574 100644 --- a/xep-0260.xml +++ b/xep-0260.xml @@ -33,6 +33,12 @@ klaus.hartke@googlemail.com nx@jabber.org + + 0.7 + 2011-08-31 + psa +

Per feedback from the XMPP Council, changed some implementation guidelines from normative to informative and modified the security considerations to remove user interface recommendations and the recommendation to use XTLS (since it is not longer being actively developed).

 + 0.6 2011-08-26 @@ -314,7 +320,7 @@ priority = (2^16)*(type preference) + (local preference)

The transport negotiation is completed in one of the following ways:

    -
  1. If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically IBB; see the Fallback Methods section of this document for details.
    2. +
  2. If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically (but not necessarily) IBB; see the Fallback Methods section of this document for details.
  3. If one of the parties sends a candidate-error notification and the other party sends a candidate-used notification, then the candidate-used shall be considered the nominated candidate.
  4. If both parties send a candidate-used notification but the candidates have a different priority, then the candidate with the higher priority shall be considered the nominated candidate.
  5. If both parties send a candidate-used notification with candidates having the same priority, then the candidate chosen by the initiator shall be considered the nominated candidate (this is consistent with the rules in XEP-0166).
    6. @@ -388,7 +394,7 @@ priority = (2^16)*(type preference) + (local preference) -

    If the SOCKS5 Bytestreams negotiation fails, the parties might want to "fall back" to the transport of last resort, which for a streaming transport is typically &xep0047; as described for Jingle in &xep0261;. The protocol flow is as follows.

    +

    If the SOCKS5 Bytestreams negotiation fails, the parties might want to "fall back" to another transport. Currently the transport of last resort for a streaming exchange is &xep0047; as described for Jingle in &xep0261;, however if other transport methods are defined in the future (e.g. &ice-tcp;) then clients could fall back to those methods instead of IBB. The protocol flow for fallback from S5B to IBB is as follows.

    ]]> -

    Now the parties can send data using In-Band Bytestreams as defined in XEP-0047.

    +

    Now the parties can send data using In-Band Bytestreams as defined in XEP-0261 and XEP-0047.

     -

    The same processing rules and usage guidelines defined in XEP-0065 apply to the Jingle S5B Transport Method. Additional implementation suggestions are:

    +

    The same processing rules and usage guidelines defined in XEP-0065 apply to the Jingle S5B Transport Method. This document adds the following implementation suggestions in the context of Jingle:

      -
    1. A client SHOULD try the offered candidates in the order of their priority, from highest to lowest.
      2. -
    2. If more than one <candidate/> element is present in a session-initiate or session-accept, a client SHOULD wait 200ms before trying the next one.
      3. -
    3. If the other party offered a direct connection and a proxy connection, its peer MAY wait a little bit longer than 200ms before trying the first proxy.
      4. -
    4. A client SHOULD NOT wait for a TCP timeout on connect. If it is unable to connect to any candidate within 5 seconds it SHOULD send a candidate-error to the other party.
      5. +
    5. Try the offered candidates in the order of their priority, from highest to lowest.
      6. +
    6. Stagger the connection attempts (e.g., initiate communications with the highest-priority candidate, then wait 200ms before initiating communications with the second-highest-priority candidate).
      7. +
    7. To increase the potential for using a direct connection, consider waiting a bit longer than 200ms to initiate communications with proxy candidates.
     @@ -507,15 +512,10 @@ Romeo Juliet -

    The exchange of candidates might result in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:

    -
      -
    1. The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).
      2. -
    2. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 6121.
      3. -
    3. The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.
      4. -
    +

    The exchange of candidates might result in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client can consider that action to imply approval of IP address sharing.

     -

    A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over the bytestream, such as those described in &xtls;.

    +

    This specification, like XEP-0065 before it, does not directly support end-to-end encryption of the media sent over the transport.

         @@ -635,4 +635,9 @@ Romeo Juliet ]]>     + + +

    Thanks to Steffen Larsen, Tobias Markmann, Florian Schmaus, Kevin Smith, and Remko Tronçon for their feedback.

    +     +