mirror of https://github.com/moparisthebest/xeps
1.8rc4
This commit is contained in:
stpeter
parent
d2bef92256
commit
e2865fc841
35
xep-0065.xml
35
xep-0065.xml
|
|
@ -31,20 +31,20 @@
|
|||
&stpeter;
|
||||
&infiniti;
|
||||
<revision>
|
||||
<version>1.8rc3</version>
|
||||
<date>in progress, last updated 2010-04-14</date>
|
||||
<version>1.8rc4</version>
|
||||
<date>in progress, last updated 2011-03-21</date>
|
||||
<initials>psa</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>Removed zeroconf attribute.</li>
|
||||
<li>Changed Initiator to Requester for consistency with Jingle use cases.</li>
|
||||
<li>Removed 'sid' attribute from address query examples because it is unnecessary in that use case.</li>
|
||||
<li>Removed the anomalous Formal Use Case text for consistency with all other XEPs.</li>
|
||||
<li>Refactored the text in various ways to make it more readable.</li>
|
||||
<li>Added text about use in Multi-User Chat, including new 'dstaddr' attribute.</li>
|
||||
<li>Removed requirement that the StreamHost should not drop any bytes sent before the bytestream is activated, since that behavior introduced the possibility of a denial of service attack.</li>
|
||||
<li>Removed length limit on 'sid' attribute.</li>
|
||||
<li>Defined the security considerations in a more thorough manner.</li>
|
||||
<li>Removed the anomalous Formal Use Case text for consistency with all other XEPs.</li>
|
||||
<li>Refactored the text in various ways to make it more readable.</li>
|
||||
<li>Changed Initiator to Requester to remove ambiguity in Jingle use cases.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
|
|
@ -322,7 +322,7 @@
|
|||
<section2 topic='Process' anchor='direct-process'>
|
||||
<p>For direct connections, the process for establishing a bytestream is as follows:</p>
|
||||
<ol>
|
||||
<li><p>Requester initiates S5B negotiation with Target by sending an IQ-set that includes the full JID &LOCALFULL; and network address of StreamHost/Requester as well as the StreamID (SID) of the proposed bytestream.</p></li>
|
||||
<li><p>Requester initiates S5B negotiation with Target by sending an IQ-set that includes the full JID &LOCALFULL; and network address of StreamHost/Requester as well as the StreamID (SID) of the proposed bytestream (and, optionally, the calculated DST.ADDR value; see under <link url='#muc'>Use with Multi-User Chat</link>).</p></li>
|
||||
<li><p>Target opens a TCP socket to the specified network address at the StreamHost/Requester.</p></li>
|
||||
<li><p>Target requests SOCKS5 connection at StreamHost/Requester.</p></li>
|
||||
<li><p>StreamHost/Requester sends acknowledgement of successful connection to Target via SOCKS5.</p></li>
|
||||
|
|
@ -357,7 +357,8 @@ Requester Target
|
|||
</section2>
|
||||
<section2 topic='Protocol' anchor='direct-proto'>
|
||||
<section3 topic='Requester Initiates S5B Negotiation' anchor='direct-proto-initiate'>
|
||||
<p>To initiate an S5B negotiation with the Target, the Requester sends network address information about one or more StreamHosts to the Target. In the case of a direct connection, the Requester might include information only about itself (as shown in the following example) or about itself and a Proxy. The &QUERY; element MUST possess a 'sid' attribute the specifies the Stream ID for this bytestream and MAY possess a 'mode' attribute whose value is "tcp" (the default) or "udp" (for which see <link url='#udp'>Optional UDP Support</link>); the &QUERY; element also MUST contain one or more <streamhost/> elements, each of which MUST possess the 'host', 'jid', and 'port' attributes.</p>
|
||||
<p>To initiate an S5B negotiation with the Target, the Requester sends network address information about one or more StreamHosts to the Target. In the case of a direct connection, the Requester might include information only about itself (as shown in the following example) or about itself and a Proxy.</p>
|
||||
<p>The &QUERY; element MUST contain one or more <streamhost/> elements, each of which MUST possess the 'host', 'jid', and 'port' attributes. The &QUERY; element MUST possess a 'sid' attribute that specifies the Stream ID for this bytestream. The &QUERY; element MAY possess a 'mode' attribute whose value is "tcp" (the default) or "udp" (for which see <link url='#udp'>Optional UDP Support</link>). The &QUERY; element MAY possess a 'dstaddr' attribute whose value is the Requester's calculated hash value for the SOCKS5 DST.ADDR field (see <link url='#muc'>Use with Multi-User Chat</link>).</p>
|
||||
<example caption='Requester Initiates Negotiation'><![CDATA[
|
||||
<iq from='requester@example.com/foo'
|
||||
id='hu3vax16'
|
||||
|
|
@ -393,7 +394,7 @@ Requester Target
|
|||
<p>If the Target is able to open a TCP socket on a StreamHost/Requester, it MUST use the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with <cite>RFC 1928</cite>, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document.</p>
|
||||
<p>Once the Target has successfully authenticated with the StreamHost/Requester, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply:</p>
|
||||
<ol>
|
||||
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary).</li>
|
||||
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under <link url='#muc'>Use with Multi-User Chat</link>, the DST.ADDR value might have been provided directly from the Requester to the Target).</li>
|
||||
<li>The port MUST be 0 (zero).</li>
|
||||
<li>The JIDs provided MUST be the JIDs used for the IQ exchange between the Requester and the Target, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.</li>
|
||||
<li>The appropriate stringprep profiles (as specified in &xmppcore;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
|
||||
|
|
@ -445,7 +446,7 @@ STATUS = X'00'
|
|||
<p>For mediated connections, the process for establishing a bytestream is as follows:</p>
|
||||
<ol>
|
||||
<li><p>As a precondition, the Requester optionally discovers the network address of StreamHost over XMPP as discussed in the <link url='#disco'>Service Discovery</link> section of this document.</p></li>
|
||||
<li><p>Requester initiates S5B negotation with Target by sending IQ-set that includes the JabberID and network address of StreamHost as well as the StreamID (SID) of the proposed bytestream.</p></li>
|
||||
<li><p>Requester initiates S5B negotation with Target by sending IQ-set that includes the JabberID and network address of StreamHost as well as the StreamID (SID) of the proposed bytestream (and, optionally, the calculated DST.ADDR value; see under <link url='#muc'>Use with Multi-User Chat</link>).</p></li>
|
||||
<li><p>Target opens a TCP socket to the selected StreamHost.</p></li>
|
||||
<li><p>Target requests SOCKS5 connection at StreamHost/Proxy.</p></li>
|
||||
<li><p>StreamHost sends acknowledgement of successful connection to Target via SOCKS5.</p></li>
|
||||
|
|
@ -501,7 +502,8 @@ Requester Proxy Target
|
|||
</section2>
|
||||
<section2 topic='Protocol' anchor='mediated-proto'>
|
||||
<section3 topic='Requester Initiates S5B Negotiation' anchor='mediated-proto-initiate'>
|
||||
<p>To initiate an S5B negotiation with the Target, the Requester sends network address information about one or more StreamHosts to the Target. In the case of a mediated connection, the Requester might include information only about the Proxy (as shown in the following example) or about the Proxy and itself. The &QUERY; element MUST possess a 'sid' attribute the specifies the Stream ID for this bytestream and MAY possess a 'mode' attribute whose value is "tcp" (the default) or "udp" (for which see <link url='#udp'>Optional UDP Support</link>); the &QUERY; element also MUST contain one or more <streamhost/> elements, each of which MUST possess the 'host', 'jid', and 'port' attributes.</p>
|
||||
<p>To initiate an S5B negotiation with the Target, the Requester sends network address information about one or more StreamHosts to the Target. In the case of a mediated connection, the Requester might include information only about the Proxy (as shown in the following example) or about the Proxy and itself.</p>
|
||||
<p>The &QUERY; element MUST contain one or more <streamhost/> elements, each of which MUST possess the 'host', 'jid', and 'port' attributes. The &QUERY; element MUST possess a 'sid' attribute that specifies the Stream ID for this bytestream. The &QUERY; element MAY possess a 'mode' attribute whose value is "tcp" (the default) or "udp" (for which see <link url='#udp'>Optional UDP Support</link>). The &QUERY; element MAY possess a 'dstaddr' attribute whose value is the Requester's calculated hash value for the SOCKS5 DST.ADDR field (see <link url='#muc'>Use with Multi-User Chat</link>).</p>
|
||||
<example caption='Requester Initiates Negotiation'><![CDATA[
|
||||
<iq from='requester@example.com/foo'
|
||||
id='npq71g53'
|
||||
|
|
@ -523,7 +525,7 @@ Requester Proxy Target
|
|||
<p>If the Target is able to open a TCP socket on the Proxy, it uses the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with <cite>RFC 1928</cite>, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document.</p>
|
||||
<p>Once the Target has successfully authenticated with the Proxy, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply:</p>
|
||||
<ol>
|
||||
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by <cite>RFC 3174</cite>; and the output is hexadecimal-encoded (not binary).</li>
|
||||
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under <link url='#muc'>Use with Multi-User Chat</link>, the DST.ADDR value might have been provided directly from the Requester to the Target).</li>
|
||||
<li>The port MUST be 0 (zero).</li>
|
||||
<li>The JIDs provided MUST be the JIDs used for the IQ exchange between the Requester and the Target, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.</li>
|
||||
<li>The appropriate stringprep profiles (as specified in <cite>XMPP Core</cite>) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
|
||||
|
|
@ -599,8 +601,8 @@ STATUS = X'00'
|
|||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use with Multi-User Chart' anchor='muc'>
|
||||
<p>When one occupant of a &xep0045; conference sends an S5B invitation to another occupant, the MUC room obscures the real JID of the Target from the Requester and the real JID of the Requester from the Target. This means that the two parties do not have the same view of the information needed to calculate the DST.ADDR. To overcome this problem, the Requester SHOULD calculate the DST.ADDR based on the SID, its real JID, and the room JID (room@host/nick) of the Target, then include the calculated hash as the value of a 'dstaddr' attribute on the &QUERY; element. The Requester then sends the IQ-set to the Target's room JID because it does not know the Target's real JID.</p>
|
||||
<section1 topic='Use with Multi-User Chat' anchor='muc'>
|
||||
<p>When one occupant of a &xep0045; conference sends an S5B invitation to another occupant, often the MUC room obscures the real JID of the Target from the Requester and the real JID of the Requester from the Target. This means that the two parties might not have the same view of the information needed to calculate the DST.ADDR. To overcome this problem, the Requester SHOULD calculate the DST.ADDR based on the SID, its real JID, and the room JID (room@host/nick) of the Target, then include the calculated hash as the value of a 'dstaddr' attribute on the &QUERY; element. The Requester then sends the IQ-set to the Target's room JID because it does not know the Target's real JID.</p>
|
||||
<p>An example follows.</p>
|
||||
<example caption='Requester Initiates Negotiation Through MUC Room'><![CDATA[
|
||||
<iq from='requester@example.com/foo'
|
||||
|
|
@ -743,8 +745,9 @@ DATA = (payload)
|
|||
<section1 topic='Formal Description' anchor='desc'>
|
||||
<section2 topic='<query/> Element' anchor='desc-query'>
|
||||
<p>The <query/> element is the container for all in-band communications. This element MUST be qualified by the "http://jabber.org/protocol/bytestreams" namespace. Depending on the use case, this element contains multiple <streamhost/> elements, a single <streamhost-used/> element, or a single <activate/> element.</p>
|
||||
<p>The 'sid' attribute specifies the bytestream session identifier. The value of this attribute is any character data.</p>
|
||||
<p>The 'mode' attribute specifies the mode to use, either "tcp" or "udp". If this attribute is not included, the default value of "tcp" MUST be assumed.</p>
|
||||
<p>The 'sid' attribute specifies the bytestream session identifier. The value of this attribute is any character data. This attribute is REQUIRED.</p>
|
||||
<p>The 'mode' attribute specifies the mode to use, either "tcp" or "udp". If this attribute is not included, the default value of "tcp" MUST be assumed. This attribute is OPTIONAL.</p>
|
||||
<p>The 'dstaddr' attribute specifies the Requester's calculated value for the DST.ADDR field and is communicated from Requester to Target in certain situations (see <link url='#muc'>Use with Multi-User Chat</link>). This attribute is OPTIONAL.</p>
|
||||
<p>The <streamhost/> element conveys the network connection information. At least one instance MUST be present in the initial IQ-set from the Requester to the Target. If multiple instances of this element are present, each one MUST be a separate host/port combination.</p>
|
||||
<p>The <streamhost-used/> element informs the Requester about the StreamHost to which the Target has connected. It MUST be present in the IQ-set from the Target to the Requester, and there MUST be only one instance.</p>
|
||||
<p>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 Requester to the Proxy after the Requester receives an IQ-result from the Target, and there MUST be only one instance.</p>
|
||||
|
|
@ -754,7 +757,7 @@ DATA = (payload)
|
|||
<p>The "jid" attribute specifies the StreamHost's JID. This attribute MUST be present, and MUST be a valid JID for communication over XMPP.</p>
|
||||
<p>The "host" attribute specifies the host to connect to. This attribute MUST be present. The value MUST be either an IPv4 or IPv6 address, or a resolvable DNS domain name.</p>
|
||||
<p>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. If not specified, the port value is "1080" (in accordance with <cite>RFC 1928</cite>).</p>
|
||||
<p>When communicating the available hosts, the Requester MUST the host and port.</p>
|
||||
<p>When communicating the available hosts, the Requester MUST include the host and port.</p>
|
||||
</section2>
|
||||
<section2 topic='<streamhost-used/> Element' anchor='desc-streamhost-used'>
|
||||
<p>The <streamhost-used/> element informs the Requester about the StreamHost to which the Target has connected. This element has a single attribute for the JID of the StreamHost to which the Target connected. This element MUST NOT contain any XML character data or child elements.</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue