diff --git a/xep-0234.xml b/xep-0234.xml index c439cbef..5b1150ce 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -26,13 +26,13 @@ &stpeter; 0.9 - 2009-02-11 + 2009-02-19 psa @@ -131,8 +131,8 @@

The initiator then sends a Jingle session-initiation request to a potential responder. The content-type of the request specifies two things:

    @@ -245,147 +245,7 @@ Initiator Responder ]]>

    Now the parties exchange the file using SOCKS5 Bytestreams.

    Once the transfer is completed, either party can terminate the Jingle session.

    -

    More detailed scenarios follow.

    - - - - -

    Currently, XEP-0096 does not enable the parties to fall back to a second method (e.g., In-Band Bytestreams) if the first method tried (e.g., SOCKS5 Bytestreams) does not work. This problem is addressed by Jingle. Such a fallback scenario is especially helpful when re-using the existing SOCKS5 Bytestreams method, since if a SOCKS5 relay is not available then the S5B method does not necessarily result in NAT or firewall traversal and therefore can result in a failed attempt at setting up the initial transport. However, because In-Band Bytestreams almost always succeeds (except if the parties violate rate-limiting policies at their servers), it provides a reliable transfer method of last resort. To provide seamless fallback, the initiator or responder can counter-propose IBB if S5B setup fails.

    -

    The session flow is as follows.

    - | - | ack | - |<----------------------------| - | [ SOCKS5 failure! ] | - |x---------------------------x| - | transport-replace (IBB) | - |---------------------------->| - | ack | - |<----------------------------| - | session-accept | - |<----------------------------| - | ack | - |---------------------------->| - | [ file transfer via IBB] | - |============================>| - | terminate | - |<----------------------------| - | ack | - |---------------------------->| - | | - ]]> -

    The protocol flow is as follows.

    -

    First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams.

    - - - - - - - This is a test. If this were a real file... - - - - - - - - - - - ]]> -

    The responder immediately acknowledges receipt of the session-initiate.

    - - ]]> -

    The initiator then attempts to initiate a SOCKS5 Bytestream with the responder as defined in xep-jingle-s5b and XEP-0065. Here we assume that the responder tries but is unable to connect to any of the StreamHosts. However, all is not lost, because the parties can attempt to fall back to In-Band Bytestreams. Therefore the initiator sends a transport-replace action including a transport of IBB.

    - - - - - - - - ]]> -

    The responder then acknowledges the transport-replace action.

    - - ]]> -

    If the transport replacement is acceptable, the responder then sends a session-accept action to the initiator (if not, the responder sends a transport-reject action).

    - - - - - - - This is a test. If this were a real file... - - - - - - - - ]]> -

    The initiator acknowledges the Jingle session-accept action.

    - - ]]> -

    Now the initiator sends the file using In-Band Bytestreams as defined in xep-jingle-ibb and XEP-0047.

    -     +

    For a description of the transport fallback scenario (from SOCK5 Bytestreams to In-Band Bytestreams), refer to XEP-0260.