[standards-jig] Thoughs about DSPS/JOBS

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Tue Nov 26 18:16:35 UTC 2002


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.

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.

JOBS attempts (and many/most believe succeeds) to address the issues of
multi-casting data in a reliable, authenticated manner, with as little
overhead as necessary.  It provides for third-party participation
(proxying), and limits the scope to still be quite usable to known
application sets; file transfer (this being a "degenerate" case),
multi-media conferencing/streaming, and even (server-controlled) gaming

If you want DTCP to replace JEP-0042, you need to fix all of DTCP's

The current authentication scheme offers very little assurance that
someone hasn't stolen the connection by getting there first.  This
drafting, in my opinion less secure than the previous, relies on shared
persistent keys, that are given little to no protection.  How do I
really know that the person connecting is the one I sent the connect

The current specification does not allow for a "third-party" (e.g.
proxy), without using "non-normative" methods (SOCKS).  This is
extremely problematic in today's world of firewalls and NATs.  Just
having someone's IP address does not mean that person's firewall will
let you connect.  Yet this is the assumption that DTCP makes.  This does
not match with reality.

Solving #1 adequately means DTCP ends up becoming JOBS, and JOBS is
already out there.  Why have two identical (or at least highly similar)

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

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