[standards-jig] Thoughts about DSPS/JOBS

Matthew A. Miller linuxwolf at outer-planes.no-ip.COM
Thu Nov 28 02:27:23 UTC 2002


First let's address port forwarding again.  Most home-consumer level
routers (< $500) are not capable of doing both stateful packet
inspection *and* port forwarding.  You get either one or the other. 
Since the users of such boxes have generally been warned of the dangers
of *not* running stateful packet inspection, they'll refuse to do
port-forwarding.

Also, Ben Schumacher noted that many providers are starting to use a
NAT/firewall before entering the user's home.  Simply setting up a port
forward then becomes practically impossible.
88
Next, the point about direct point-to-point connectivity.  I should have
made this clearer:  I was not trying to say JOBS wasn't capable of
direct point-to-point connectivity, but that DTCP precluded any
possiblity of this (and yet, was suggested to be appropriate to use DTCP
for JOBS' out-of-band conversations).

In fact, the JOBS specification does allow for direct point-to-point
connectivity.  This is also a requirement for the environments that I
had intended JOBS for.  There are various points within JEP-0042 that
note what would be necessary when operating this way.  In a nutshell,
for direct point-to-point operation (if any points are missed in
JEP-0042, then please point them out so I can resolve them):

1)  The sender configures the session locally.  How exactly this is done
is an implementation detail, but must have a port available for
accepting connection, and a "session ID" to associate.  The entire
creation IQ-steps are skipped.

2)  The sender sends out the invites themselves.  Again, the minimum
information that must be provided is a hostname and port number to
connect to, and the session ID to associate with.

3)  Authentication is still necessary, but the sender is acting as the
JOBS server.

4)  The authorization steps are now handled locally, in an
implementation-dependent way.

5)  The sender is responsible for sending the various action='notify'
messages.

6)  Deleting a session is done locally, and is also
implementation-dependent.


I hope this addresses some of your concerns.


-  LW

On Wed, 2002-11-27 at 17:53, Hal Rottenberg wrote:
> Matthew and Justin,
> 
> While perusing the archives I saw a discussion about JOBS vs DTCP that
> looked interesting and thought I might comment.
> 
> <quote author="matthew">
> On the subject of Corporate Users:  Like it or not, corporations make
> the world go round.  They drive development of technology much more than
> the home-consumer level.
> 
> The JSF has a responsibility to provide a set of standards that make
> technical sense to the most number of entities, which includes both of
> the above groups.  DTCP does not even attempt to work for the corporate
> use-cases, and works "most of the time" (and much, much less over time)
> for the second group.  JOBS solves the problem for both.
> </quote>
> 
> It seems to me that JOBS, while being arguably more compatible to a
> greater number of configurations, is not necessarily the best choice for
> the greatest _number_of_users_.  Let me explain.
> 
> The both of you have overlooked a third case where messages and OOB data
> would be transferred.  That third case is point-to-point connections, on
> the same IP network, _behind_ the corporate firewall or NAT router.  In
> case you do not think this is a significant case, at the Fortune 50
> company I work for, we have just shy of 10,000 users on our Jabber
> server.
> 
> Sending email attachments is extremely popular at work.  Drives the
> Exchange admins crazy I bet.  If a small subset of our Jabber users were
> to drop email attachments for Jabber file xfer, I can see it squashing
> our Jabber server pretty quickly.  As you say, "Any Jabber server could
> have several set up for discovery (and not even on
> their own resources), possibly even load-balanced (which looks like one,
> humoungous server).".  We would definitely have to do this.  It would
> cost a lot of money in additional server hardware and labor.
> 
> Alternatively, users could DTCP to each other.  No muss, no fuss, more
> evenly distributed load on the networks, no additional central costs.
> 
> Then to address the home users with routers--I venture to say that most
> of them know how to forward a port *.  Regardless, client negotiation
> and discovery will figure out the best way. 
> 
> (* Just had a thought--Universal Plug & Play Gateway Extensions might be
> able to fill in for the rest who do not know how to forward a port...)
> 
> I for one can definitely see a need for both protocols.
> 
> -hal
> email: hal at nx2k.com
> JID: halr9000 at theoretic.com
> AIM: halr9000
> "Insert clever signature here."
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-- 
Matt "linuxwolf" Miller
E-MAIL: linuxwolf at outer-planes.net
JID:    linuxwolf at outer-planes.net

- Get JABBER! (http://www.jabber.org/)




More information about the Standards mailing list