[standards-jig] JEP 65 - Bytestreams
me at pgmillard.com
Wed Dec 18 17:47:40 UTC 2002
Justin Karneges wrote:
> On Tuesday 17 December 2002 08:35 pm, Dave Smith wrote:
>> _PLEASE_ comment.
> 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.
"Competition" and discussion is a _VERY_ good thing when designing
protocols. If the consensus of the community is that JEP-65 is a good/better
implementation of the same problem as JEP-46, then the community should try
and come to some resolution around the issue and NOT have both JEP's being
sent to the council for vote. We as a community need to resolve the issue
before we reach that point in the process. (The current discussion seems to
be helping, and driving to a resolution). In the end, we should have "one
JEP standing", the one that the community has conensus on and is the best
way to solve the problems.
I'm going to try and wear both hats (council member, and client author) for
the following comments, so take them in that context.
> 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.
As a client author, I tend to like -65 better since it disallows the chaotic
nature of multiple connections being attempted at once, this flow each
entity trying to contact the other on potentially up to 3 sockets just seems
to lead to a state chart that I'm not sure I want to implement.
> Personally, I just want a standard already.
Here is a statement everyone can agree on :)
> 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.
And no one is saying that the research and "elaboration" of JEP-46 is for
naught... If we didn't have it as a starting point for these discussions, we
would not have been able to get this far down the protocol design road. I
"commend" you on the initial research and extensive CPU cycles you've put
into this problem space.
> [SNIP..] 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
But other people (me included) do have significant issues with DTCP as it
stands now.. Let me explain:
- Assume you changed the wire protocol to be SOCKS5 ala JEP-65...
- Assume JEP-52 says that for jabber "file transfers" mandate that HTTP be
used as the transfer mechanism once a bytestream has been established...
- I still have issues w/ the chaos of mutliple entities attempting multiple
connections at once.. If we change that, than what we have left is basically
JEP-65. Specifically, this sentence, REALLY scares me about implementations:
"As such, clients that are listening for connections should be prepared for
- JEP-65 also has fewer round-trip IQ packets (which is also easier to
- JEP-46 specifies a <ssl/> identifier. IMO, this is outside the scope of a
bytestream... if the protocol I want to use supports SSL, then maybe I use
it. IE, the context and protocol of the bytestream should dictact if SSL is
possible. e.g. maybe I want to use SMTP over my bytestream... so I could
ELHO and the existing START-TLS stuff which already exists.
- JEP-46 forces clients to use different protocol for proxies, and for p2p
connections (it uses different namespaces and DTDs). This should be seamless
(as JEP-65 does).
Having implemented the many of the clients that LOTS of people use, I'd have
to say that having simpler code is _ALWAYS_ better.. Easier state charts
mean less bugs. Period. Thats mostly why I'd prefer -65 to -46 at this
> 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.
Well, this is the price you pay for implementing something that has not been
approved by the community or the council. As a client author, I have waited
at least for community consensus on a protocol before implementing anything
in Exodus. When I was developing Winjab, I often used it as a test-bed for
experimental protocols, and it led to complete code chaos. It _IS_ valuable
to prototype these sorts of things, but "production" clients and servers are
not the place. This is where high level languages like C#, Java, Python,
etc... are great.
> [SNIP..] 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.
If another existing JEP has consensus (note that consensus != unanimous) in
the community, then thats the JEP that should move forward, and all other
JEPs which are trying to solve the problem should be withdrawn IMO. I think
we'll see the same thing happen as we try move to some kind of consensus
around the pub-sub JEPs. It is my hope (as a council member) that the old
p/s JEPs will either be "withdrawn" (if no implementations exist), or moved
to Information (if implementations do exist), once the community rallies
around one specific JEP. The nature of standards dictact that there exist
exactly 1 standard for each problem space being address, not multiples.
> 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.
I _REALLY_ like the idea of using SOCKS as a wire protocol, since there are
TONS of client library implementations. The spec is well defined and easy to
implement, and it's an IETF standard. All of which are BIG points (for both
council reasons and client author reasons). IMO, using SOCKS is a perfect
case of re-use of existing std protocols. We don't do this enough in jabber
My previous comments about the issues around -46 should be sufficient.. I
don't think we should go through the effort of trying to solve these issues
in -46, when they are already solved in -65!?
>> Please consider this JEP as a candidate for a community driven
JEP-65 is something I can get behind, JEP-46 is NOT at this point.
More information about the Standards