[standards-jig] JEP 65 - Bytestreams

Thomas Muldowney temas at box5.net
Wed Dec 18 19:38:27 UTC 2002


Here I was thinking I'd have to make a long reply to this thread, but
PGM's comments are right on with mine.  I really can't add anything
else.

--temas


On Wed, Dec 18, 2002 at 10:47:40AM -0700, Peter Millard wrote:
> 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
> > solution.
> 
> 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
> anything."
> - JEP-65 also has fewer round-trip IQ packets (which is also easier to
> implement).
> - 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
> stage.
> 
> > 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.
> 
> [SNIP...]
> 
> > 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
> >> standard.
> 
> JEP-65 is something I can get behind, JEP-46 is NOT at this point.
> 
> pgm.
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021218/0b972528/attachment.sig>


More information about the Standards mailing list