[standards-jig] JEP 65 - Bytestreams

Justin Karneges justin-jdev at affinix.com
Wed Dec 18 14:31:03 UTC 2002

On Tuesday 17 December 2002 08:35 pm, Dave Smith wrote:
> _PLEASE_ comment.

Well, you already know my opinion, but I will write to the list to keep 
everyone in the loop.  I do hope someone else will comment besides me. :)

> following the upcoming holidays. Additionally, I am encouraging client
> authors and Council members to review and try and implement the
> specification laid out in this JEP. Finally, I hope to see the File
> Transfer JEP (JEP 052) adjusted to specify how it could use JEP 65 and
> JEP 47 to perform file transfers.

I understand the need to solve this problem, and there are various methods of 
going about it.  Introducing a competing JEP while DTCP is in Last Call is 
not going to get us a solution any faster though.  It would be one thing if 
DTCP were some informational draft, and JEP 65 was intended to replace it.  
Instead, these are two specifications in direct competition of each other 
(they do exactly the same thing), and this would likely only cause the 
council to throw up their hands once they set to vote on JEP 46.

Having a differing opinion is fine, and I like how you've laid everything out 
in JEP 65.  However, in the interest of everyone seeking a standard, I 
suggest we combine our efforts into one JEP, particularly into DTCP so that 
the council can vote on it "real soon now".  Peter should make an extension 
to the Last Call, to give us more time to discuss.

Personally, I just want a standard already.  I don't really see any problems 
in your JEP 65, and had I not written JEP 46, I would probably use your spec 
in my client.  However, back in May when I first investigated this topic, 
there was no such JEP, and I had to come up with my own solution.  Your JEP 
65 actually reminds me of some early ideas I was kicking around for DTCP.  
This is not to say anything bad about your JEP, but I do feel that DTCP may 
be more optimized for the job.  After months of tweaking the specification 
and my implementation, I believe I have come up with a solid solution.

It is important to also consider that there are several implementations of 
DTCP already: tkabber, imcom, psi.  As the author of the latter, I can say 
that I would rather not change my specification a whole lot from the current 
draft.  I can't speak for the others, but I would really like them to comment 
(aleksey, casey?).  However, I don't think this should be construed as an act 
of stubbornness.  True, DTCP is not a standard yet, but as I mentioned above, 
it is also not 'informational' either.  That is, it is not waiting for a 
replacement.  If there are areas that need improvement, then there is no need 
to throw out the entire specification when the existing one can simply be 
improved.  I feel I have already come up with some nice solutions to the 
critiques of DTCP (see my recent posts to this list), like for proxying, 
which I was the most stubborn about initially.

Now, getting to the actual specs themselves.  JEP 46 and 65 essentially do the 
same thing.  The end goal is to have a TCP stream between two entities.  You 
lay out some good points of 65:

> * Uses an IETF standard protocol for the out-band negotiation (SOCKS5)
> * Supports proxied bytestreams

Now how do we make DTCP just as capable?  Consider this revision of my 
document, which supports proxying:

This leaves the wire protocol, which is actually quite easy to change.  My 
resistance to HTTP in earlier discussion is mainly because I felt it was 
unnecessary syntax.  Your idea of using SOCKS seems like a better fit for an 
arbitrary bytestream.

What do others think about the use of SOCKS ?  If there are developers not 
satisified with the 'proprietary' DTCP handshake, would a SOCKS-based 
protocol be interesting?  As it stands, I still don't see the need to create 
an entirely new specification, when we can just roll good ideas back into JEP 
46.  SOCKS could very well be one of those good ideas, and Diz of course 
would be credited.

> Please consider this JEP as a candidate for a community driven standard.

This is fair, and I would be interested to see comments from other client 
developers as well.  As stated above, I'm mostly interested in just getting a 
capable spec, of which both of ours are, soon standardized.  Even though I 
may prefer my spec, if everyone else prefers your spec then we'll go with 
yours!  Very simple.

_PLEASE_ comment, people !  :)


More information about the Standards mailing list