[Standards] Questions regarding XEP-0065
stpeter at jabber.org
Fri Apr 13 19:15:26 UTC 2007
Matthias Wimmer wrote:
> Hi Peter!
> Peter Saint-Andre schrieb:
>> AFAIK, we always use hex encoded SHA1 output in our protocols. We can
>> make that explicit in XEP-0065.
> That's what I expected, I just wanted to be sure.
>>> - In the Reply packet for the socks server to the connect request,
>>> the server transmits the IP address and port that the server uses to
>>> connect to the destination. As XEP-0065 does not really do SOCKS5,
>>> but only uses the syntax of SOCKS5, the proxy will not connect on
>>> this request. So what is expected to be transmitted as this address
>>> and port in the connect reply?
>> It's not clear to me exactly what you are referring to in the spec.
>> Which example is this?
> None ... it's in RFC 1928, section 6 ("Replies").
> The general SOCKS5 reply message is: VER (X'05'), REP (X'00' by
> XEP-0065), RSV (X'00' by RFC 1928), ATYPE (addresstype X'01', X'03' or
> X'04'), BND.ADDR, BND.PORT.
> For the reply to the CONNECT request RFC1928 reads:
> "In the reply to a CONNECT, BND.PORT contains the port number that the
> server assigned to connect to the target host, while BND.ADDR contains
> the associated IP address. The supplied BND.ADDR is often different from
> the IP address that the client uses to reach the SOCKS server, since
> such servers are often multi-homed. [...]"
I don't think that XEP-0065 proxies will ever be multi-homed, so what
Justin does in Iris seems appropriate (just set BND.ADDR and BND.PORT to
the DST.ADDR and DST.PORT from the connection request). This is what
proxy65 does as well.
> Another question (a new one):
> In XEP-0065 section 8.2, table 2 ATYP is mapped to have the value 1, 3
> or 4. Are we really every using 1 (IPv4 address) or 4 (IPv6 address) in
> a request? Aren't we always using 3 (originally 'domainname' but we are
> using it to contain the hash).
Yes, we are.
> BTW: The crippled usage of SOCKS5 syntax but not protocol in XEP-0065 is
> one of the reasons I really look forward to do file transfers using
We need to figure out exactly what that means. Suggestions welcome. :)
> But I guess on the server side I have to support XEP-0096 or
> better XEP-0096-to-Jingle translation for some time ;-)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards