[standards-jig] Thoughs about DSPS/JOBS

Justin Karneges justin-jdev at affinix.com
Wed Nov 27 01:05:50 UTC 2002


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!

I think there should only be one spec for this sort of thing, and so I 
understand that one should get voted out (and one has).  However, I still 
don't see how JOBS is any better than DSPS just from the JEPs.  It would have 
been nice if the voters had actually made mention of how these compare, but 
perhaps they did and I missed it..

> Next, if you find JOBS overly complicated, then you should say why.  If
> you can't back up an argument, you shouldn't start one.  There are
> plenty of reasons to explain why an implementation hasn't surfaced yet,
> not the least of which is that this JEP is still EXPERIMENTAL, and
> therefore still (possibly) subject to lots and lots of changes.  That
> said, I've gotten started on an implementation (server), and hopefully
> should have it available by the beginning of the year.

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.

> 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.

> 1) LACK OF RELIABLE AUTHENTICATION:

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.

> 2) LACK OF PROXY SUPPORT

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.

> 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.

> 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.

-Justin

> On Sat, 2002-11-23 at 02:15, Justin Karneges wrote:
> > Hi all,
> >
> > I was thinking about JEP-37 and 42, and how they:
> >
> > 1) are overcomplicated
> > 2) are lots of work to implement
> > 3) have no proposed applications
> >
> > As it stands, no one is rushing to implement them.  After spending a
> > considerable amount of time implementing JEP-46 (DTCP), I would not want
> > to code yet-another-tcp-system that is even more complex.
> >
> > Perhaps #1 could be addressed by simplifying these protocols to not
> > include anything related stream formation.  Instead, they could use DTCP
> > as a basis. And not just DTCP, how about IBB also?  Then this
> > multicasting server component thing could interact with clients in
> > multiple ways.  And with the bulk of the complicated stream stuff
> > removed, it wouldn't be so daunting to implement.
> >
> > -Justin
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig




More information about the Standards mailing list