[standards-jig] Re: [JDEV] DSPS

Dave Smith dizzyd at jabber.org
Wed Jul 24 14:43:36 UTC 2002


FWIW, I like the concept of PASS and/or DSPS. I think it's necessary to 
move Jabber forward.

I would say also that I think the DSPS document is slightly more 
complicated than necessary (i.e. relay stuff) -- what if we had a 
modified version of the DSPS JEP with the relay stuff as optional?

Diz

On Wednesday, July 24, 2002, at 07:51 , Matthew A. Miller wrote:

> Many within the Jabber Community are finding the need for something like
> DSPS.  This is why it was brought forward (well, that and the somewhat
> general consensus that PASS is lacking (-: ).  If you believe a
> SOCKS-based approach meets these needs better, then by all means draft
> up a JEP, so we can discuss it!
>
> DSPS is about a little more than just "breaching firewalls".  It also
> handles stream negotiation, from within the Jabber protocol.  Yes, if a
> "direct" socket connections were possible, DSPS might not be necessary.
> But "direct" means that Jabber entities, on any networked environment,
> can establish this type of connection.  Certain environments (Java
> Applets being just one example) generally do not allow arbitrary stream
> connections.
>
> Finally, DSPS is a proposed "standard" to the Jabber protocol.  This
> means that (if DSPS is voted in by the Council) application developers
> can rely on a known way to handle stream negotiation.  JEPs are more
> than just <x/> or <query/> add-ons; they define "accepted practices" for
> Jabber application development.
>
> Since you see a SOCKS-based solution, then please draft up a JEP or even
> some simple "process thoughts".  Anything that we can then discuss the
> merits, and possibly compare/contrast to DSPS (or other proposals).
>
> I think competition is generally a Good Thing(TM) (-:
>
>
> On Wed, 2002-07-24 at 01:34, Richard Dobson wrote:
>> Yes but if a SOCKS server will not be setup and it is because of 
>> network
>> security etc then you shouldnt really be trying any method of 
>> breaching the
>> firewall, as that will most likely be against company network use 
>> policies
>> and could quite possibly get you sacked.
>>
>> Sorry to put a dampener on this it looks for for some uses (helping 
>> people
>> with home nats) but it has problems where it may be possibly breaching
>> security policies, it may also cause the network admins to actively 
>> block
>> all jabber connections if they find people using it to breach network
>> security even if they wernt too worried about it being a threat before.
>>
>> Richard
>>
>> ----- Original Message -----
>> From: "Dave" <dave at dave.tj>
>> To: <jdev at jabber.org>
>> Sent: Wednesday, July 24, 2002 2:03 AM
>> Subject: Re: [JDEV] DSPS
>>
>>
>>> Often, the problem is not technical (a SOCKS server can't be setup 
>>> because
>>> it'd compomise network security), but is rather administrative (a 
>>> SOCKS
>>> server can't be setup because there's too much beauracracy involved,
>>> plus the possibility that the network admin is too scared to poke 
>>> holes
>>> in his firewall, not realizing that allowing outgoing connections is
>>> already poking a hole big enough for people to create virtual incoming
>>> connections).  Also, an old hardware-based firewall may not even 
>>> support a
>>> SOCKS add-on.  Finally, there's no real reason for people to have to 
>>> setup
>>> a rather complex piece of software on their firewalls just so they can
>>> transfer files in Jabber; let them use a server-based solution 
>>> instead.
>>>
>>>  - Dave
>>>
>>> BTW - Due to my bad luck at avoiding running over my quota for daily
>>> messages when answering your emails, I don't plan to reply to any more
>>> messages in this thread.
>>>
>>>
>>> Richard Dobson wrote:
>>>>
>>>> Why not just get people to use SOCKS5 ?? or similar instead of 
>>>> trying to
>>>> reinvent the wheel as it were. If on a corporate LAN and there is a
>> firewall
>>>> with no SOCKS server then people probably shouldnt really be trying 
>>>> to
>>>> bypass the company firewall anyway. If not then they need to pester 
>>>> the
>>>> network manager to set up a SOCKS server to service the jabber 
>>>> clients.
>>>>
>>>> ----- Original Message -----
>>>> From: "Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com>
>>>> To: "JDEV Mailing List" <jdev at jabber.org>; <standards-jig at jabber.org>
>>>> Sent: Tuesday, July 23, 2002 7:51 PM
>>>> Subject: Re: [JDEV] DSPS
>>>>
>>>>
>>>>> The original intent of DSPS was to address the problems transferring
>>>>> data to/from "firewalled" clients, without introducing new issues 
>>>>> (as
>>>>> with PASS).
>>>>>
>>>>> The current spec talks solely about components, although a
>> "stand-alone"
>>>>> server could be utilized.  Also, although it is not by design, this
>>>>> could handle direct connections, with one of the clients acting as a
>>>>> DSPS "server" (for connection-handling only; I know I wouldn't want
>>>>> someone trying to tell my client to create a DSPS connection for 
>>>>> them
>>>>> (-: ).  This (a client-side DSPS "server") is something I've thought
>>>>> about just recently, while looking at how we can "clean up" the
>> current
>>>>> specification.
>>>>>
>>>>> At its core, DSPS is fairly easy to support from a client (as others
>>>>> have stated).  Also, it's "required" functionality (which, I admit, 
>>>>> is
>>>>> not clearly differentiated from "optional" functionality) is not all
>>>>> that difficult to implement, and (with modifications, or a new spec)
>>>>> could be used in direct, P2P connections.
>>>>>
>>>>> Personally, I think a single "standardized" method of handling "data
>>>>> connections" needs to be defined for Jabber, whether it be via DSPS,
>>>>> PASS, or even modifications to the current OOB mechanism.  
>>>>> Currently,
>> I
>>>>> can see DSPS as becoming an adequate, maybe even preferred, method 
>>>>> of
>>>>> doing this.
>>>>>
>>>>> This is my opinion, although your mileage (and opinions) may (most
>>>>> likely) vary.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 2002-07-23 at 10:50, Ben Schumacher wrote:
>>>>>     (Cross-posting, cause I think it applies to both lists.)
>>>>>
>>>>>     I agree, that using a stream layer separate from the file 
>>>>> transfer
>>>> would
>>>>>     be preferred, I just think we shouldn't rely on a server as a
>> passthru
>>>> in
>>>>>     all situations. Working around firewall issues is a problem that
>> has
>>>> been
>>>>>     solved by nearly every peer-to-peer network in existence, so I
>> assume
>>>>>     there has to be a solution that will work for Jabber. In fact, 
>>>>> by
>>>> keeping
>>>>>     the stream layer separate, it should be possible to initiate the
>>>> connect
>>>>>     from either side and then do a data transfer in either 
>>>>> direction.
>> This
>>>> way
>>>>>     if I am behind a firewall, but the person I'm communicating with
>>>> isn't, I
>>>>>     can open a connection to them and then push my data across.
>> Perhaps
>>>> the
>>>>>     DSPS spec should be expanded/altered to the point where it 
>>>>> doesn't
>>>>>     necessarily imply that a proxy is necessary.
>>>>>
>>>>>     Currently, the server doesn't have any knowledge of what a 
>>>>> user's
>> IP
>>>> is
>>>>>     beyond socket creation, and I would guess that this will stay 
>>>>> this
>> way
>>>> in
>>>>>     the open source implementation -- it is a privacy concern, after
>> all.
>>>> That
>>>>>     being said, however, it would be pretty easy to write something
>> that
>>>> would
>>>>>     have this information (a DSPS component?) available if it was
>>>> necessary.
>>>>>
>>>>>     Does any of this make sense? I'm just trying to avoid
>>>> designing/developing
>>>>>     something that will not be used, because servers probably won't
>> want
>>>> to
>>>>>     take the extra bandwidth hit just to provide their users with 
>>>>> the
>>>> ability
>>>>>     to do file transfers.
>>>>>
>>>>>     bs.
>>>>>
>>>>>     On Tue, 23 Jul 2002, Justin Karneges wrote:
>>>>>> The problem is that there is otherwise no real clean way to
>>>> establish a direct
>>>>>> connection.  Everyone is behind a firewall these days.
>>>>>>
>>>>>> Maybe jabberd should support a way of getting your external IP
>>>> address, so
>>>>>> that there could be some sort of stream negotiation between two
>>>> clients.  As
>>>>>> it stands, clients don't even know what their real external
>> address
>>>> is unless
>>>>>> you were to specify it directly (not exactly user-friendly).
>>>>>>
>>>>>> The "stream" idea IMO makes more sense than just http URLs,
>> because
>>>> it implies
>>>>>> more possibilities than just file transfer.  It also keeps the
>>>> stream
>>>>>> handshake as a separate layer, which simplifies things when you
>>>> consider the
>>>>>> various possible methods of transport (TCP, DSPS, PASS,
>>>> XML-thru-server??),
>>>>>> SSL, reverse-connections, etc.  I completely agree with Rob
>> about
>>>> keeping the
>>>>>> stream layer _separate_ from the file transfer.
>>>>>>
>>>>>> DSPS is dead-easy to use from a client perspective.  What we
>> need is
>>>> something
>>>>>> similar to it, as a standard part of jabberd, that allows
>> clients to
>>>> ask for
>>>>>> a stream to another JID.  Something very simple like:  "Oh, you
>> want
>>>>>> joe at blow.org/Home?  Connect to this IP address."  This might be
>>>> through DSPS,
>>>>>> or it might be direct, or whatever.  I'm just saying, we need a
>>>> simple way
>>>>>> for clients to ask for a stream.  DSPS seems to have a nice
>>>> interface, but it
>>>>>> assumes we want to route through an external point.  Maybe the
>> real
>>>> solution
>>>>>> is to have an even smarter component that will hook you up
>> directly
>>>> to the
>>>>>> other person if possible, otherwise fall back to DSPS (all
>> hiding
>>>> this from
>>>>>> the client).
>>>>>>
>>>>>> The current situation is not optimal.
>>>>>>
>>>>>> -Justin
>>>>>
>>>>>     _______________________________________________
>>>>>     jdev mailing list
>>>>>     jdev at jabber.org
>>>>> http://mailman.jabber.org/listinfo/jdev
>>>>> --
>>>>>
>>>>> Matt "Linuxwolf" Miller
>>>>>
>>>>> - Got "JABBER"? (http://www.jabbercentral.org/)
>>>>>
>>>>> _______________________________________________
>>>>> jdev mailing list
>>>>> jdev at jabber.org
>>>>> http://mailman.jabber.org/listinfo/jdev
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jdev mailing list
>>>> jdev at jabber.org
>>>> http://mailman.jabber.org/listinfo/jdev
>>>>
>>>
>>> _______________________________________________
>>> jdev mailing list
>>> jdev at jabber.org
>>> http://mailman.jabber.org/listinfo/jdev
>>>
>>
>>
>> _______________________________________________
>> jdev mailing list
>> jdev at jabber.org
>> http://mailman.jabber.org/listinfo/jdev
> --
>
> Matt "Linuxwolf" Miller
> e-mail && jid:  linuxwolf at outer-planes.net
>
> - got JABBER? (http://www.jabbercentral.org/)
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
>




More information about the Standards mailing list