[standards-jig] JEP 65 - Bytestreams
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
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