JEP-0065: SOCKS5 Bytestreams

This JEP defines a protocol for establishing a bytestream between any two Jabber entities.

NOTICE: The protocol defined herein is a Draft Standard of the Jabber Software Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

JEP Information

Status: Draft
Type: Standards Track
Number: 0065
Version: 1.5
Last Updated: 2004-06-29
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: bytestreams
Schema: <http://jabber.org/protocol/bytestreams/bytestreams.xsd>

Author Information

Dave Smith

Email: dizzyd@jabber.org
JID: dizzyd@jabber.org

Matthew Miller

Email: linuxwolf@outer-planes.net
JID: linuxwolf@outer-planes.net

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction
2. Terminology
2.1. Conformance Terms
2.2. Architectural Terms
3. Narrative
3.1. Direct Connection
3.2. Mediated Connection
4. Protocol
4.1. Initiator Queries Target Regarding Bytestreams Support
4.2. Initiator Queries Server For Proxies
4.3. Initiator Queries Proxy to Find Out if it is a Proxy
4.4. Initiator Discovers Network Address of StreamHost
4.5. Initiator Informs Target of StreamHosts
4.6. Target Establishes SOCKS5 Connection with StreamHost
4.7. Target Acknowledges SOCKS5 Connection
4.8. Initiator Establishes SOCKS5 Connection with StreamHost
4.9. Activation of Bytestream
5. Formal Use Case
5.1. Primary Flow
5.2. Alternate Flows
6. Formal Description
6.1. <query/> Element
6.2. <streamhost/> Element
6.3. <streamhost-used/> Element
6.4. <activate/> Element
7. Implementation Notes
7.1. StreamHost Requirements
7.2. SOCKS5 Parameter Mapping
8. Security Considerations
9. IANA Considerations
10. Jabber Registrar Considerations
10.1. Protocol Namespaces
10.2. Service Discovery Category/Type
11. Schema
Notes
Revision History

1. Introduction

It is widely recognized within the Jabber community that it would be valuable to have a generic protocol for streaming binary data between any two entities on the network. The main application for such a bytestreaming technology would be file transfer, for which there are currently a number of incompatible protocols (resulting in a lack of interoperability). However, other applications are possible, which is why it is important to develop a generic protocol rather than one that is specialized for a particular application such as file transfer. This JEP proposes a protocol that meets the following conditions:

Specifically, this JEP proposes that the Jabber community make use of the SOCKS 5 protocol, which is an IETF-approved, IPv6-ready technology for bytestreams. (Note: because this proposal uses a subset of the SOCKS5 protocol that is specially adapted for Jabber bytestreams, existing SOCKS5 proxies CANNOT be used to implement this proposal.)

2. Terminology

2.1 Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

2.2 Architectural Terms

Table 1: Glossary of Entities

Term Description
Initiator A Jabber Entity that wishes to establish a bytestream with another Entity
Target The Entity with which the Initiator is attempting to establish a bytestream
Proxy A Jabber entity which is not NAT/Firewalled and is willing to be a middleman for the bytestream between the Initiator and the Target
StreamHost The system that the Target connects to and that is "hosting" the bytestream -- may be either the Initiator or a Proxy
StreamID A relatively unique Stream ID for this connection; this is generated by the Initiator for tracking purposes and MUST be less than 128 characters in length

3. Narrative

There are two scenarios addressed by this protocol:

  1. direct connection (i.e., the StreamHost is the Initiator)
  2. mediated connection (i.e., the StreamHost is a Proxy)

The "happy paths" for these scenarios are described separately below for ease of understanding. A full description of these scenarios is captured in the Formal Use Case.

3.1 Direct Connection

Direct connection is the simpler case. In this situation, the StreamHost is the Initiator (StreamHost/Initiator), which means that the Initiator knows the network address of the StreamHost and knows when to activate the bytestream. The process for establishing bytestreams in this case is as follows:

  1. Initiator sends IQ-set to Target specifying the full JID and network address of StreamHost/Initiator as well as the StreamID (SID) of the proposed bytestream.

  2. Target opens a TCP socket to the specified network address.

  3. Target requests connection via SOCKS5, with the DST.ADDR and DST.PORT parameters set to the values defined below.

  4. StreamHost/Initiator sends acknowledgement of successful connection to Target via SOCKS5.

  5. Target sends IQ-result to Initiator, preserving the 'id' of the initial IQ-set.

  6. StreamHost/Initiator activates the bytestream.

  7. Initiator and Target may begin using the bytestream.

3.2 Mediated Connection

Mediated connection is slightly more complicated. In this situation, the StreamHost is not the Initiator but a Proxy, which means that the Initiator must discover the network address of the StreamHost before sending the initial IQ-set, must negotiate a connection with the StreamHost in the same way that the Target does, and must request that the StreamHost activate the bytestream before it can be used. The process for establishing bytestreams in this case is as follows:

  1. Initiator discovers the network address of StreamHost in-band. [optional]

  2. Initiator sends IQ-set to Target specifying the full JID and network address of StreamHost as well as the StreamID (SID) of the proposed bytestream.

  3. Target opens a TCP socket to the selected StreamHost.

  4. Target establishes connection via SOCKS5, with the DST.ADDR and DST.PORT parameters set to the values defined below.

  5. StreamHost sends acknowledgement of successful connection to Target via SOCKS5.

  6. Target sends IQ-result to Initiator, preserving the 'id' of the initial IQ-set.

  7. Initiator opens a TCP socket at the StreamHost.

  8. Initiator establishes connection via SOCKS5, with the DST.ADDR and DST.PORT parameters set to the values defined below.

  9. StreamHost sends acknowledgement of successful connection to Initiator via SOCKS5.

  10. Initiator sends IQ-set to StreamHost requesting that StreamHost activate the bytestream associated with the StreamID.

  11. StreamHost activates the bytestream. (Data is now relayed between the two SOCKS5 connections by the proxy)

  12. StreamHost sends IQ-result to Initiator acknowledging that the bytestream has been activated (or specifying an error).

  13. Initiator and Target may begin using the bytestream.

4. Protocol

4.1 Initiator Queries Target Regarding Bytestreams Support

Before attempting to initiate a bytestream, the Initiator may want to know if the Target supports the bytestream protocol. It may do so using Service Discovery [2] as follows:

Example 1. Initiator Sends Service Discovery Request to Target

<iq 
    type='get' 
    from='initiator@host1/foo' 
    to='target@host2/bar' 
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

If the Target's client supports bytestreams, it MUST answer to that effect in the service discovery result.

Example 2. Target Replies to Service Discovery Request

<iq 
    type='result' 
    from='target@host2/bar' 
    to='initiator@host1/foo' 
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity 
        category='proxy'
        type='bytestreams'
        name='SOCKS5 Bytestreams Service'/>
    ...
    <feature var='http://jabber.org/protocol/bytestreams'/>
    ...
  </query>
</iq>

4.2 Initiator Queries Server For Proxies

Before attempting to initiate a bytestream, the Initiator needs to find a proxy. It may do so using Service Discovery as follows:

Example 3. Initiator Sends Service Discovery Request to Server

<iq 
    type='get' 
    from='initiator@host1/foo'
    to='host1' 
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

The server will return all of the known JIDs in its disco list.

Example 4. Server Replies to Service Discovery Request

<iq 
    type='result' 
    from='host1' 
    to='initiator@host1/foo' 
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    ...
    <item jid='proxy.host3' name='Bytestreams Proxy'/>
    ...
  </query>
</iq>

4.3 Initiator Queries Proxy to Find Out if it is a Proxy

For each item in the disco#items result, the client must ask them if they are a bytestreams proxy. It may do so using Service Discovery as follows:

Example 5. Initiator Sends Service Discovery Request to Proxy

<iq 
    type='get' 
    from='initiator@host1/foo'
    to='proxy.host3' 
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

The proxy will return its information. The client should look in each identity to see if it contains an indentity in the category "proxy" and type "bytestreams".

Example 6. Server Replies to Service Discovery Request

<iq 
    type='result' 
    from='proxy.host3' 
    to='initiator@host1/foo' 
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <identity category='proxy'
              type='bytestreams'
              name='SOCKS5 Bytestreams Service'/>
    ...
  </query>
</iq>

4.4 Initiator Discovers Network Address of StreamHost

If the StreamHost is a Proxy, the Initiator must first request the full network address used for bytestreaming (obviously this is not required if the StreamHost is the Initiator). This is done by sending an IQ-get to the proxy in the bytestreams namespace, as follows:

Example 7. Initiator Requests Network Address from Proxy

<iq 
    type='get' 
    from='initiator@host1/foo' 
    to='proxy.host3' 
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'/>
</iq>

The <streamhost/> element containing network address MUST include the following attributes:

In addition, the <streamhost/> element MUST include:

EITHER

OR

If included, the zeroconf [3] service identifier and protocol name SHOULD be "_jabber.bytestreams".

Example 8. Proxy Informs Initiator of Network Address

<iq 
    type='result' 
    from='proxy.host3' 
    to='initiator@host1/foo' 
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'>
    <streamhost 
        jid='proxy.host3' 
        host='24.24.24.1' 
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

If the Initiator does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation may enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a "Forbidden" error to the Initiator (for information about error syntax, refer to Error Condition Mappings [4]):

Example 9. Proxy Returns Error to Initiator

<iq type='error' 
    from='initiator@host1/foo' 
    to='proxy.host3' 
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'/>
  <error code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the Proxy is unable to act as a StreamHost, the Proxy SHOULD return a "Not Allowed" error to the Initiator:

Example 10. Proxy Returns Error to Initiator

<iq type='error' 
    from='initiator@host1/foo' 
    to='proxy.host3' 
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'/>
  <error code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

4.5 Initiator Informs Target of StreamHosts

In order to establish a bytestream between the Initiator and the Target, the Initiator must provide network address information for the StreamHost(s) to the Target. This happens in-band via a single IQ-set, which must contain the following information:

The protocol format is shown below.

Example 11. Initiation of Interaction

<iq 
    type='set' 
    from='initiator@host1/foo' 
    to='target@host2/bar' 
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams' sid='mySID'>
    <streamhost 
        jid='initiator@host1/foo' 
        host='192.168.4.1' 
        port='5086'/>
    <streamhost 
        jid='proxy.host3' 
        host='24.24.24.1' 
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

If the Target is unwilling to accept the bytestream, it MUST return a "Not Acceptable" error to the Initiator.

Example 12. Target Refuses Bytestream

<iq type='error' 
    from='target@host2/bar' 
    to='initiator@host1/foo' 
    id='initiate'>
  <error code='406' type='auth'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

4.6 Target Establishes SOCKS5 Connection with StreamHost

If the Target is willing to accept the bytestream, it MUST attempt to open a standard TCP socket on the network address of the StreamHost communicated by the Initiator. If the Initiator provides more than one StreamHost, the Target SHOULD try to connect to them in the order they occur.

If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return a "Not Found" error to the Initiator.

Example 13. Target Is Unable to Connect to Any StreamHost and Wishes to End Transaction

<iq type='error' 
    from='target@host2/bar' 
    to='initiator@host1/foo' 
    id='initiate'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the Target is able to open a TCP socket on a StreamHost, it MUST utilize the SOCKS5 protocol specified in RFC 1928 [5] to establish the connection with the StreamHost. In accordance with the SOCKS5 RFC, the Target MAY have to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this JEP. Once the Target has successfully authenticated with the Proxy (even anonymously), it SHOULD make a CONNECT request to a host named: SHA1(SID + Initiator JID + Target JID), port 0, where the SHA1 hashing algorithm is specified by RFC 3174 [6]. The JIDs provided MUST be full JIDs (i.e., <user@host/resource>); furthermore, in order to ensure proper results, the appropriate stringprep profiles (as specified in XMPP Core [7]) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.

Example 14. Target Connects to StreamHost

CMD = X'01'
ATYP = X'03'
DST.ADDR = SHA1 Hash of: (SID + Initiator JID + Target JID)
DST.PORT = 0

Example 15. StreamHost Acknowledges Connection

STATUS = X'00'

4.7 Target Acknowledges SOCKS5 Connection

After the Target has authenticated with the StreamHost, it MUST send an IQ-result to the Inititator indicating which StreamHost was used.

Example 16. Target Notifies Initiator of Connection

<iq 
    type='result' 
    from='target@host2/bar' 
    to='initiator@host1/foo' 
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'>
    <streamhost-used jid='proxy.host3'/>
  </query>
</iq>

At this point, the Initiator knows which StreamHost was used by the Target.

4.8 Initiator Establishes SOCKS5 Connection with StreamHost

If the StreamHost used is a Proxy, the Initiator MUST authenticate and establish a connection with the StreamHost before requesting that the StreamHost activate bytestream. The Initiator will establish a connection to the SOCKS5 proxy in the same way the Target did, passing the same value for the CONNECT request.

4.9 Activation of Bytestream

In order for the bytestream to be used, it MUST first be activated by the StreamHost. If the StreamHost is the Initiator, this is straightforward and does not require any in-band protocol. However, if the StreamHost is a Proxy, the Initiator MUST send an in-band request to the StreamHost. This is done by sending an IQ-set to the Proxy.

Example 17. Initiator Requests Activation of Bytestream

<iq 
    type='set' 
    from='initiator@host1/foo' 
    to='proxy.host3' 
    id='activate'>
  <query xmlns='http://.jabber.org/protocol/bytestreams' sid='mySID'>
    <activate>target@host2/bar</activate>
  </query>
</iq>

Note that the <activate> element encapsulates the Target's full JID. Using this information, with the SID and from address on the packet, the Proxy can activate the stream by hashing the SID + Initiator JID + Target JID. This provides a reasonable level of trust that the activation request came from the Initiator.

If the Proxy can fulfill the request, it MUST then respond to the Initiator with an IQ-result.

Example 18. Proxy Informs Initiator of Activation

<iq 
    type='result' 
    from='proxy.host3' 
    to='initiator@host1/foo' 
    id='activate'/>

The Proxy MUST then send acknowledgement of the connection to the Target.

Example 19. StreamHost Acknowledges Connection to Target

STATUS = X'00'

If the Proxy cannot fulfill the request, it MUST return an IQ-error to the Initiator; the following conditions are defined:

5. Formal Use Case

This is a formal representation of the narrative information provided above. The primary actor is the Initiator and the goal is to establish a bytestream between the Initiator and the Target. (Note: "UCE" stands for "Use Case Ends" (success is assumed unless otherwise specified) and "P" stands for "Primary Flow", and "A" stands for "Alternate Flow".)

5.1 Primary Flow

  1. Initiator wishes to establish a bytestream with Target
  2. Initiator sends an IQ-set to Target specifying a StreamID and the network addresses of one or more StreamHosts [A1]
  3. Target wishes to establish a bytestream with Initiator [A2]
  4. Target requests TCP connection with a StreamHost [A3]
  5. Target receives TCP acknowledgement from StreamHost [A4]
  6. Target provides authentication credentials to StreamHost via SOCKS5
  7. Target receives acknowledgement of authentication with StreamHost via SOCKS5 [A5]
  8. Target requests connection with StreamHost via SOCKS5
  9. Target sends IQ-result to Initiator announcing successful connection to StreamHost [A6]
  10. Target receives acknowledgement of successful connection with StreamHost via SOCKS5 [A7]
  11. Use Case Ends (bytestream is established and ready for use)

5.2 Alternate Flows

A1. Initiator does not know the full network address of a StreamHost (i.e., Proxy)

  1. Initiator sends IQ-get to Proxy
  2. Initiator receives IQ-result from Proxy containing network address [A9][A10]
  3. Return to P2

A2. Target does not wish to establish a bytestream with Initiator

  1. Initiator receives "Not Acceptable" error from Target
  2. UCE unsuccessfully

A3. No more StreamHosts in list (Target is unable to reach any of the provided StreamHosts)

  1. Target returns "Remote Server Error" error to Initiator
  2. UCE unsuccessfully

A4. Target cannot reach StreamHost

  1. Return to P4

A5. Target authentication with StreamHost fails

  1. Return to P4

A6. Proxy is unwilling to act as a StreamHost for Initiator

  1. Initiator receives "Forbidden" error from Proxy
  2. Return to P2

A7. Proxy is unable to act as a StreamHost for Initiator

  1. Initiator receives "Not Allowed" error from Proxy
  2. Return to P2

A8. Target connects to a Proxy

  1. Initiator reaches Proxy [A9]
  2. Target receives TCP acknowledgement from StreamHost [A9]
  3. Initiator authenticates with Proxy via SOCKS5
  4. Initiator receives acknowledgement of authentication with Proxy via SOCKS5 [A10]
  5. Initiator requests connection with Proxy via SOCKS5
  6. Initiator receives acknowledgement of successful connection with Proxy via SOCKS5 [A11]
  7. Initiator sends IQ-set to Proxy requesting activation of bytestream
  8. Initiator receives IQ-result from Proxy acknowledging activation of bytestream [A12]
  9. Return to P9

A9. Initiator is unable to reach Proxy

  1. UCE unsuccessfully

A10. Initiator is unable to authenticate with Proxy

  1. UCE unsuccessfully

A11. Initiator is unable to connect to Proxy

  1. UCE unsuccessfully

A12. Proxy is unable to activate bytestream

  1. Initiator receives "Internal Server Error" error from Proxy
  2. UCE unsuccessfully

6. Formal Description

6.1 <query/> Element

The <query/> element is the container for all in-band communications. This element MUST be in the namespace "http://jabber.org/protocol/bytestreams". This element has a single attribute for the stream session identifier, and contains multiple <streamhost/> elements, a single <streamhost-used/> element, or a single <activate/> element.

The "sid" specifies the bytestream session identifier. This attribute MUST be present. The value of this attribute is any character data.

The <streamhost/> element conveys the network connection information. At least one instance MUST be present in the initial IQ-set from the Initiator to the Target. If multiple instances of this element are present, each one MUST be a separate host/port combination.

The <streamhost-used/> element transports the out-of-band token. It MUST be present in the IQ-set from the Target to the Initiator, and there MUST be only one instance.

The <activate/> element is used to request activation of a unidirectional or bidirectional bytestream. It MUST be present in the IQ-set sent from the Initiator to the StreamHost after the Initiator receives an IQ-result from the Target, and there MUST be only one instance.

6.2 <streamhost/> Element

The <streamhost/> element contains the bytestream connection information. This element has attributes for the StreamHost's JID, network host/address, and network port. This element MUST NOT contain any content nodes.

The "jid" attribute specifies the StreamHost's JID. This attribute MUST be present, and MUST be a valid JID for use with an <iq/>.

The "host" attribute specifies the host to connect to. This attribute MUST be present. The value MUST be either a resolvable domain name or the "dotted decimal" IP address (e.g. "1.2.3.4").

The "port" attribute specifies the port to connect to. This attribute MAY be present. The value MUST be a valid port number in decimal form.

The "zeroconf" attribute specifies the zero-configuration service available for bytestreaming. This attribute SHOULD be present. The value SHOULD be '_jabber.bytestreams'.

When communicating the available hosts, the Initiator MUST include EITHER the host and port OR the zeroconf information.

6.3 <streamhost-used/> Element

The <streamhost-used/> element indicates the StreamHost connected to. This element has a single attribute for the JID of the StreamHost to which the Target connected. This element MUST NOT contain any content node.

The "jid" attribute specifies the full JID of the StreamHost. This attribute MUST be present, and MUST be a valid JID for use with an <iq/>.

6.4 <activate/> Element

The <activate/> element is a flag to trigger a Proxy to complete a connection.

7. Implementation Notes

7.1 StreamHost Requirements

A StreamHost SHOULD (but is not required to) do the following:

  1. Allow bi-directional bytestreaming between the Initiator and Target.
  2. Allow only one Target to connect to a bytestream (i.e., disallow multicasting).
  3. Track sessions based on a combination of the StreamID and the Initiator's full JID, thus allowing an Initiator to create more than one simultaneous session.
  4. Ignore but not drop any bytes sent before the bytestream is activated.
  5. Prefer to use zero-configuration IP networking if supported.

In addition, a StreamHost MAY ignore the DST.ADDR and DST.PORT parameters if desired.

7.2 SOCKS5 Parameter Mapping

To facilitate the usage of SOCKS5, command parameters MUST be mapped to the appropriate values. Parameters not specified in the table below SHOULD be used as defined in RFC 1928.

Table 2: Request/Parameter Mapping

Parameter Value
CMD 1 (CONNECT)
ATYP 1 (IP V4), 3 (DOMAINNAME), or 4 (IP V6)
DST.ADDR SHA1 Hash of: (SID + Initiator JID + Target JID)
DST.PORT 0

8. Security Considerations

This proposal does not include a method for securing or encrypting SOCKS5 bytetreams. If such security is desired, it MUST be negotiated over the bytestream (once established) using standard protocols such as SSL or TLS. Negotiation of such security methods is outside the scope of this JEP.

9. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].

10. Jabber Registrar Considerations

10.1 Protocol Namespaces

The 'http://jabber.org/protocol/bytestreams' namespace is registered in the protocol namespaces registry maintained by the Jabber Registrar [9].

10.2 Service Discovery Category/Type

The Jabber Registrar shall add the "proxy" category and associated "bytestreams" type to the Service Discovery registry. The submission is as follows:

  <category>
    <name>proxy</name>
    <desc>Proxy servers or services</desc>
    <type>
      <name>bytestreams</name>
      <desc>A proxy for SOCKS5 bytestreams</desc>
      <doc>JEP-0065</doc>
    </type>
  </category>

11. Schema 

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/bytestreams'
    xmlns='http://jabber.org/protocol/bytestreams'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      JEP-0065: http://www.jabber.org/jeps/jep-0065.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:choice>
        <xs:element ref='streamhost' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='streamhost-used' minOccurs='0'/>
        <xs:element name='activate' type='empty' minOccurs='0'/>
      </xs:choice>
      <xs:attribute name='sid' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='streamhost'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='required'/>
          <xs:attribute name='host' type='xs:string' use='required'/>
          <xs:attribute name='srvid' type='xs:string' use='optional'/>
          <xs:attribute name='port' type='xs:string' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='streamhost-used' type='xs:string'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Notes

1. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <http://www.ietf.org/rfc/rfc2119.txt>.

2. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

3. Zeroconf is a set of protocols that enable IP networking without the need for configuration. For further information, refer to <http://www.zeroconf.org/>.

4. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.

5. RFC 1928: SOCKS Protocol Version 5 <http://www.ietf.org/rfc/rfc1928.txt>.

6. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>.

7. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

9. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

Revision History

Version 1.5 (2004-06-29)

Added requirement to apply stringprep profiles before SHA1 hashing; added reference to RFC 3174. (psa)

Version 1.4 (2004-06-28)

Cleaned up narratives to reflect current practices and removed unnecessary authentication references; fixed mismatch SOCKS5 parameter table values. (ds)

Version 1.3 (2003-09-24)

Added disco#info <identity/> and corresponding Jabber Registrar submission; added XMPP error handling. (psa)

Version 1.2 (2003-07-15)

Removed SIDs from the result queries, you should key off the IQ 'id' attribute instead. Added the disco exchange for finding available proxies. (rwe)

Version 1.1 (2003-07-09)

Changed srvid to zeroconf; cleaned up use cases; updated the schema. (ds)

Version 1.0 (2003-04-21)

Per a vote of the Jabber Council, advanced status to Draft. (psa)

Version 0.7 (2003-03-04)

Clarified that this proposal uses an adaptation of the SOCKS5 protocol, not the full protocol; replaced DTD with schema; added security considerations. (psa)

Version 0.6 (2003-01-27)

Added service discovery example; added 'srvid' attribute to streamhost element and required inclusion of either 'srvid' or 'port' attribute; improved the algorithms for generating SOCKS5 UNAME and PASSWD parameters; specified that the DST.ADDR and DST.PORT parameters may be ignored; removed references to connected/disconnected notification, bidirectional bytestreams, and multiple targets; updated implementation notes. (psa/ds)

Version 0.5 (2002-12-20)

Specified option of "reversing the connection" (Target becomes Initiator); added more error cases; resurrected and cleaned up formal use case. (psa)

Version 0.4 (2002-12-19)

Added section on connected/disconnected notifications sent from Proxy to Initiator; cleaned up several examples; specified more error conditions; clarified the formal descriptions; added implementation notes and future considerations. (psa, mm)

Version 0.3 (2002-12-17)

Added lots of detail to the narrative and protocol. (psa)

Version 0.2 (2002-12-16)

Added SOCKS info. (ds)

Version 0.1 (2002-12-13)

Initial version. (ds)

END