[standards-jig] Thoughs about DSPS/JOBS

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Wed Nov 27 17:38:26 UTC 2002

On Tue, 2002-11-26 at 17:05, Justin Karneges wrote: 
> On Tuesday 26 November 2002 10:16 am, Matthew A. Miller wrote:
> > Justin,
> >
> > First, you need to remove JEP-0037 from all your arguments.  It's been
> > REJECTED, and the author(s) have (apparently) decided not to address the
> > council's issues.  Please do not consider this JEP any longer.
> IMO, it was unfairly voted out.  I only read the messages containing the votes 
> themselves, and of those with a reason attached no one was actually talking 
> about the spec!

Some technical-based reasons for JEP-0037 being rejected:
1)  http://mailman.jabber.org/pipermail/council/2002-October/000522.html
2)  http://mailman.jabber.org/pipermail/council/2002-October/000517.html

They don't go into a terrible amount of detail, but you can always ask
those Councilors for a more detailed explanation of "why".

> <SNIP>
> Ok, perhaps JOBS is not overly complicated, but rather "naturally" 
> complicated, due to what it is trying to achieve.  I figured this was 
> obvious, considering the number of known implementations to my knowledge was 
> zero, and so I didn't consider backing up anything.

The lack of an implementation does not mean it's overly complicated.  In
fact, Disco (JEP-0030) has little/no implementations that are commonly
known, yet no one is claiming it (in and of itself) is overly
complicated.  Rather, it's being proposed for "Draft" status as we
speak.  The same goes for x-commands (JEP-0050).

> > If you want DTCP to replace JEP-0042, you need to fix all of DTCP's
> > flaws:
> First, I did not propose replacing JOBS with DTCP.  Rather, I proposed using 
> DTCP as a basis for JOBS, so that client authors could use the same TCP code 
> they already have.

You are proposing to eliminate the OOB headers side of JOBS, which is
pretty core to its functionality.  Layering those on top of DTCP just
adds (IMO wasteful) overhead, and possibly a false sense of reliability
(since the connection will terminate if the entity cannot be

> I really would like someone to explain to me how DTCP's current authentication 
> is any worse than JOBS, when I would think both are vulnerable to line 
> tapping.

I said AUTHENTICATION, not ENCRYPTION.  Line tapping is irrelevant in
this argument.  However, the very classic "man-in-the-middle" attack is
still a significant factor, and JOBS at least attempts to address this. 
DTCP does not.

Without adequate AUTHENTICATION, you cannot provide adequate
AUTHORIZATION, and you lose the confidence of your potential user-base.

> This is intentional.  For nearly all home users, proxy support is unnecessary.  
> Yes, many people use NAT, but this is easily solved with a port-forward.  No 
> need to send all of your files through the Jabber server just because you 
> don't want to route a port.  For corporate users this may be another matter.

First, nowhere is it said that there can be only one JOBS server.  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).  Great thing, discovery:  It means you only need to
know *what* to look for, not necessarily *where* to look for it.

On the subject of Home Users:  More and more people are becoming equiped
with broadband and/or wireless, more and more people are existing behind
routers.  These routers (at the recommendation of almost every salesman,
support technician, technology journalist, and "geek") *will* have their
firewall and stateful packet inspection turned on.  The funny thing
about these inexpensive routers is, port-forwarding and stateful packet
inspection don't usually mix.  So just opening and configuration an
internal/external mapping may not even be possible.  Not everyone with a
desire to use this is a "DIY network-admin", or has the clout over their
"DIY network-admin" to do this.

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.

> > Solving #1 adequately means DTCP ends up becoming JOBS, and JOBS is
> > already out there.  Why have two identical (or at least highly similar)
> > specifications?
> "Beefing" the auth of DTCP would not make it JOBS.  DTCP allows reverse 
> connections, and is intended for P2P.  Implementing a JOBS server in a client 
> seems strange, and would defeat the multicasting argument.  These are two 
> separate protocols for separate situations.

First, what use-case *requires* reverse connections, that cannot be
handled by more conventional, and arguably more readily acceptable,

Second, P2P happens to be a "degenerate" case of multicasting, where
there's one sender and one receiver.  So I'll apply an earlier argument
you made; why have more than one protocol that (essentially) does the
same thing?

> > As for solving #2, just getting a Jabber server to tell you what IP you
> > just connected from isn't going to cut it.  There could easily be
> > multiple firewalls and/or NAT's between you and it.  And this is *not*
> > the exception, but the rule.
> On the contrary, AIM and ICQ both provide all users with internal/external IP 
> addresses.  So far this has been largely successful.

If by "largely successful" you mean "works about half the time", then
you are right.  Most of the experiences I've had or heard ofhave not

Again, it comes down to viability.  DTCP does not offer a viable
solution for most of the community, whereas JOBS does.


Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list