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).
The transport negotiation is completed in one of the following ways:
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:
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:
-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.
Thanks to Steffen Larsen, Tobias Markmann, Florian Schmaus, Kevin Smith, and Remko Tronçon for their feedback.
+